实战课堂：数据库高Library Cache Lock导致Hang的故障分析

案情描述：

客户数据库发生hang现象，大量业务操作超时，DBA介入分析。

通过OEM控制台的监控工具，可以看到客户数据库的“平均活动会话数”从21点开始active session出现明显增长，最高超过60个直至10点左右恢复。

在图上出现一个明显的“波峰”，且等待事件类为concurrency：

对于这类情况，如果数据库可以操作，我们仍然可以从ASH或者AWR入手，快速获取信息。

收集 21点至22点的AWR报告，其“Top 5 Timed Events”前两个为：library cache lock、library cache pin且平均等待时间分别为2928和2910毫秒，出现严重的性能问题。这两者的Wait Class就是Concurrency，也就是监控中所表现出来的问题。

查看AWR中“SQL ordered by Elapsed Time”可以发现所有执行时间长的语句都为调用过程和包，每次执行时间基本都是超过1秒最长达到35.9秒，远远超出了正常值：

通过以上信息进行初步分析，我们怀疑数据库缓慢的原因可能是对高使用率的核心存储过程和包进行编译导致。

该问题的发生一般伴随着“LIBRARY CACHE PIN” 和“LIBRARY CACHE LOCK”等待事件。

为了进一步确认问题，如果有相关包和存储过程在问题期间进行编译过可以通过DBA_OBJECTS视图的"LAST_DDL_TIME"字段观察到最近一次编译时间。

客户告知当晚存在对表进行添加字段的操作，经过客户与操作人员确认进行添加字段的表为MAIN.EMP_NOTE与上表格标红的行的表名和时间吻合。

存储过程或包引用的表结构发生变更时，对象会变为无效。Oracle会在第一次访问此对象时试图去重新编译它们,如果此时有其他session已经把此对象 pin到library cache中,就会因exclusive类型的pin导致出现等待,当有大量的active session并且存在较复杂的dependence时如下表，当CMP_NOTE发生改变时标红列的所有对象都需要重新编译。

原文链接