因修改數據庫賬號密碼引起的library cache lock
某晚，接到友商的電話說數據庫慢，好多服務都退出了。到現場後，在敲命令的時候發現數據庫查詢很慢很慢，以前1秒可以顯示出來的內容，現在需要5~10秒。
初步看看異常等待事件：
不難發現異常等待事件library cache lock非常地多。在過來現場的路上，讓值班重啟了一次實例。到現在剛好15分鐘，大部分應用已經退出了，為何在15分鐘內會產生那麼多的事件？
異常等待事件library cache lock在東興出現的次數不少，往往是在賦權之後出現，應用程序自己堵塞自己引起。但這套數據庫是UAT環境，賬號基本都具有select/insert/update/delete any table的權限，不存在賦權的情況。
帶著這個疑問，生成一份ASH看看：
這個毫無疑問。在Top Phases of Execution和Top Call Types發現：
什麼是OAUTH？
OAUTH協議為用戶資源的授權提供了一個安全的、開放而又簡易的標準。與以往的授權方式不同之處是OAUTH的授權不會使第三方觸及到用戶的帳號信息（如用戶名與密碼），即第三方無需使用用戶的用戶名與密碼就可以申請獲得該用戶資源的授權，因此OAUTH是安全的。oAuth是Open Authorization的簡寫。
從這裡可以看出與密碼有關。
進一步查詢：
發現NGCRM_GD用戶的LCOUNT增長迅速。基本可以確認是這個用戶造成的了。詢問友商後得知今晚剛好修改了這個賬號的密碼。
通過DDL_LOCK視圖查看：
再確認連接主機：
友商檢查程序後做修改後恢復正常。
ps:其實問題根源就是友商修改了數據庫的密碼，而應用的連接密碼未修改徹底，過多的失敗連接引起異常事件library cache lock。
到Metalink上進行查詢，發現該問題存在於Version 10.2.0.5 and later，臨時解決方案需設置事件28401
alter system set event ="28401 TRACE NAME CONTEXT FOREVER, LEVEL 1″ scope=spfile;
或者從PROFILE的FAILED_LOGIN_ATTEMPTS從UNLIMITED設置為有限次數。
閱讀更多 愛新覺羅張三丰 的文章
