1. 现象
   客户数据库在每周五出现大量的“library cache lock”等待事件，数据库业务办理失败。
3. 问题分析
   从ASH视图我们可以发现，数据库从9:01分开始出现“library cache lock”等待事件。



4. 如上图，等待事件中P3TEXT 对应的是100*mode+namespace，对于的P3RAW十六进制值为52002。namespace 52转为相应的十进制为82，mode为2。



5. 通过查询82对应的具体library cache操作类型为“SQL AREA BUILD”



6. library cache lock中“SQL AREA BUILD”对应的原因大部分都是SQL解析失败的原因导致。通过在测试数据库对该问题进行测试重现，在v$sysstat视图可以看到数据库有明显的SQL解析错误的情况。



7. 通过设置10035 event将解析错误的SQL打印到alert日志，找出具体的解析错误SQL。
   ALTER SYSTEM SET EVENTS ‘10035 trace name context forever, level 1’;

我们可以看到，存在较多的解析错误的SQL，通过业务人员修复存储过程对应的错误后，再次在测试库进行相应的测试，数据库没有再出现“library cache lock”类等待事件。由此可以证明，数据库出现的大量“library cache lock”是由于存储过程语法出现错误，数据库无法进行正确的SQL解析导致。

另外数据库还存在较多的硬解析。每秒有640的硬解析次数，建议联系业务将未使用绑定变了的SQL进行绑定变量处理。

3. 结论与建议
   1、 业务修复生产库已存在错误的存储过程语句，可在后续该业务高峰期观察数据库等待事件，如果仍存在问题，可以再次打开10035 event，将问题修复。