实战课堂：数据库高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发生改变时标红列的全部对象都须要从新编译。