oracle故障处理-Library Cache Lock，Library cache: mutex X

故障现象：

下午业务高峰期收到反馈，客户生产一个SQL无法通过，所有的请求都卡在一个数据语句上。影响客户生产，所有业务人员都在线等待，十万火急紧急联系客户远程。根据业务人员描述，从业务系统界面看，卡住的都是在执行同一个操作，并且数据库迟迟没有返回，问题出在数据库层面。

故障处理：

1、登录数据库系统，三板斧之第一板斧头：查看等待事件。

select inst_id,event#,event, count(*)

from gv$session

where wait_class# != 6

group by 1, 4 desc;

查出来数据库当前有20个library cache lock 等待， 同时还有一个library cache:mutex X等待。心头一惊，一般情况下数据库SQL执行效率差可能是执行计划发生抖动导致，常规的等待事件是db file sequence read/write之类，通过执行计划绑定可以解决。这个library cache lock和library cache:mutex X发生在SGA的shared pool 锁竞争，在数据库配置SGA、sharedpool 配置正确的情况下一般不会产生。开发又折腾除了什么新的幺蛾子。

2、检查数据库配置，三板斧之二：检查数据库配置

客户的生产库版本是11.2.0.4 打了比较新的RU。物理内存256G。

2.1 library cache的锁竞争第一个考虑到的是库的SGA或者shared pool配置过小，检查SGA 配置有70G。同时SGA采用手动管理，db_cache配置40G， shared pool 配置15G，streams pool\large pool\java pool 分别配置5G. PGA 配置 20G. 整体数据库配置没问题。

2.2 library cache的锁竞争 还有一个怀疑是用户大规模的密码错误，可以通过event 设置'28401 trace name context forever,level 1'解决。该event参数也已经配置正常。并且再三咨询过现场人员没有人动过生产环境。

综上，配置问题可以排除，密码错误导致的锁竞争也可以排除。这两个常规的导致

3、检索文档，三板斧之三：查看AWR和alert日志

数据库alert日志没有啥异常的ORA报错。AWR分析如下：

3.1 Instance Efficiency Percentages (Target 100%)的Parse CPU to Parse Elapsd %: 0.41 异常低。

3.2 根据第一个线索，数据库CPU的解析效率如此低下是有问题的。 检查解析的错误比率

错误的解析比率占比94.59%。

至此已经破案，数据库在大量的解析执行错误的SQL语句，导致shared pool 内存锁，从而hang住整个SQL。

根据检索，找到一个相关的文档。

'Library Cache Lock', 'Library cache: mutex X' and High Parse Failures Rates with 'Error=936' (Doc ID 2515981.1)

根据文档的解决方案。设置一个数据库的10035事件,抓取错误的解析语句。

---打开10035抓取错误解析语句

ALTER SYSTEM SET EVENTS '10035 trace name context forever, level 1';

---关闭10035抓取

ALTER SYSTEM SET EVENTS '10035 trace name context off';

故障总结：

数据库打开10035抓取的一瞬间，alert日志大量的解析错误语句爆出来，还是同一个。发给研发。研发人员分析判断。程序的SQL语句中调用了一个函数，该函数会对表里面的一个字段做计算。如果该字段为空，则在函数里面会执行一个错误的SQL。同时该表的记录有二十几万，等于一次请求，没一行都会执行一个错误的SQL，从而导致数据库有大量的解析错误。最终产生library cache lock。

该函数已经存在有十几年了，开发人员写的函数对数据的考虑不全面。