實戰課堂：數據庫高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發生改變時標紅列的全部對象都須要從新編譯。