Oracle failed parse elapsed time造成卡顿处理

客户生产9:00-10:00数据库卡顿

以下截取部分AWR报告:

整体来说，通过结合昨天AWR分析，认为本次卡顿不是SQL书写效率层面的问题,认为是SQL解析失败导致的.那么是什么情况导致的大量的SQL解析失败，第一想到的一定是BUG。

AWR报告中值得关注还有library cache lock library cache: mutex X
那么接下来的问题就是排查failed parse elapsed time等待事件的起因:
failed parse elapsed time 等待事件意味着当我们的 sql 在进行硬解析的时候，出现了错误。
主要产生错误的原因可能包含：SQL 语法错误，对象不存在，没有足够的权限等。

从图中可以看出硬解析总次数以及失败解析的次数.与客户沟通看下是否存在批量SQL执行操作.

其后迅速采用10035事件跟踪观察解析失败的SQL：

SQL> alter session set events ‘10035 trace name context forever,level 1’;
Session altered
然后在trace中发现不断出现错误SQL执行.

其次通过对library cache lock library cache: mutex X以及connection management call elapsed time时间模型结合分析，认为其产生的原因是由于密码延迟验证问题

通过设置EVENTS 28401来实现屏蔽密码延迟验证：
ALTER SYSTEM SET EVENT = ‘28401 TRACE NAMECONTEXT FOREVER, LEVEL 1’ SCOPE = SPFILE;
关于密码延迟验证详细看:
https://blog.****.net/baoyuhang0/article/details/109735773

记录排查文档如下：
‘Library Cache Lock’, ‘Library cache: mutex X’ and High Parse Failures Rates with ‘Error=936’ (Doc ID 2515981.1)
Resolving Issues Where High ‘failed parse elapsed time’ Seen Due to SQL Receiving Errors on Parse/Execute (文档 ID 1476070.1)
Bug 23555824 - Hang From ‘library cache lock’ and ‘library cache: mutex X’ Waits (Doc ID 23555824.8)
Document 1353015.1 How to Catch Hard Parse Errors