一次library cache lock 問題分析

說明

背景說明

台州工商行政管理局新上 RAC 資料庫，在 2015 年開始，不定期出現應用程式連線不上資料庫例項的故障，故障發生時間大多在下午 15:30-18:00 之間，資料庫發生故障期的間業務具體現象為應用程式連線資料庫出現長時間掛起現象，此時 RAC 資料庫例項與監聽均正常，只有重新啟動資料庫後應用程式方可連線資料庫。

 

 

故障初步分析

目前由於 WR 報告只能保留 7 天時間 , 最近的一次故障發生時間是 2015 年 5 月 12 日，已經超出了日誌的最大保留時間， 同時我們檢查資料庫的告警日誌，發現故障時間點的告警日誌已經被人為的刪除，從而使得故障的判斷更加困難。不過所幸我們在 /tmp 目錄下找到了故障發生時間點的 AWR 報告，應該是上蔟故障解決時遺留下來的報告。下面我們針對給出的故障時間點的 AWR 報告，進行分析並得出初步結論。

 

故障詳解

檢查故障時間點的 CPU 繁忙程度，通過 DB Time 和 Elapsed Time 比對我們可以發現：

故障時間點：

可以看到，在60 分鐘的物理時間中，DB 執行超過4000 分鐘，CPU 已經被100% 消耗。

而在正常的時間節點中，同樣的CPU 基本空閒在90% 以上。

正常業務中週期：

 

而在故障時間點的Top 10 等待事件中：

排第一位的即為 library cache lock ，一般來說，發生 library cache lock 一般是由於儲存過程在執行中被編譯，或者大量的 DDL 操作等等，不過我們檢查了相關的 AWR 故障點的報告，沒有發現可疑的 SQL 。不過在故障點的 Top 時間模型中，我們發現如下資訊：

可以看到，故障時間99% 的CPU 都消耗在connection management call elapsed time 上面，也就是說，故障點的時候99% 的CPU 都消耗在連線上面，並且我們檢查發現，在故障點發生的SQL ，和正常時間點發生的SQL ，存在很大的差別。

故障點的 SQL ：

 

正常時間節點的 SQL ：

 

由於資料有限，我們只能分析到這裡，不過結合以上資訊，我們也能夠大致分析出導致 library cache lock 的原因。

根據 MOS 文件：

High "Library Cache Locks" Wait Time Due to Invalid Login Attempts ( 文件 ID 1309738.1)

由於台州工商局核心系統，原則上不應該有這麼大的連線壓力，我們根據 AWR 報告的資訊分析，在故障發生的時候，應該是某些應用的連線出現密碼錯誤問題，導致密碼延遲登入特性被觸發，從而命中 BUG ：

Bug 19867671 : LIBRARY CACHE LOCK CAUSED BY WRONG PASSWORD LOGIN

該 BUG 觸發版本： 11.2.0.3 正好命中臺州工商的資料庫版本。並且由於客戶的資料庫錯誤密碼登入失敗次數從 10 次調整到 unlimited ：

使得問題不可能被重現。

總結

通過以上的分析對比，我們得出如下的結論：

1.        導致系統hang 住的原因是由於Library Cache Locks ，結合該時間段的AWR ，沒有發現可疑的SQL ，而在故障時間段，基本的資源都消耗在會話連線上，所以我們還是判斷資料庫在會話連線層面出現問題，根據Bug 19867671 可知，在出現錯誤密碼的時候，由於密碼延遲登入的新特性，會導致大量的密碼錯誤登入，並且，比對故障時間點的SQL 和正常時間點的SQL ，我們發現，兩者的SQL 也不太一致，很有可能是不同的業務模組在weblogic 上由於密碼的錯誤問題，導致該模組觸發該BUG 。

建議：建議根據故障觸發的時間段，結合故障時從2015 年開始觸發的，確認該時間段呼叫的業務模組是什麼，相應的中介軟體有哪些，通過對以上的中介軟體檢查密碼情況。

 

2.        調整密碼登入失敗的引數，無論是從安全形度考慮還是從排查問題角度考慮，我們都建議客戶將DEFAULT   FAILED_LOGIN_ATTEMPTS PASSWORD UNLIMITED 重新設定為10 次。

 

3.        對應的系統日誌及資料庫日誌不要隨意的刪除，方便後續的問題檢視，本次在檢查問題的時候發現，資料庫的告警日誌已經被清理，從問題的排查角度上看，對於故障時間節點的日誌，我們建議客戶保留，方便後續的問題排查。