編輯手記：library cache lock 大家都并不陌生，在mos上對該阻塞的一般成因描述為：一般可以了解的是alter table或者alter package/procedure會以x模式持有library cache lock，造成阻塞（444560.1）。但針對具體問題仍要具體分析，今天分享一則因sql綁定變量出現空值，導緻大量子遊标産生并引發library cache lock 的故障，供大家參考借鑒。
請故障現象及影響
某資料庫為oracle 11.2.0.3.9 rac linux 64bit，一天晚上9點左右，業務系統反應緩慢，資料庫曾發現有大量library cache lock等待事件，并伴随有library cache:mutex x，導緻業務系統短暫無法正常提供業務處理
問題分析
觀察ash報告，等待library cache lock會話在執行sql如下
對比上周同一天的awr，這個sql執行的次數差不多，大概半小時7萬次左右，但在23号的awr中，該sql在order by version count出現，version count為76（實際上在v$sql中發現有2萬個 不同child_address出現），說明該sql産生過2萬個子遊标。這裡也看到其他sql high version，但由于其他sql執行沒有0pjnn575vchbg頻繁，并不引發library cache lock等待。
該sql已占用了1gb的共享池空間
結合資料庫版本和環境情形，初步推斷為acs bug引發。但在關閉acs特性後，library cache lock等待事件與子遊标依然存在。
這樣排除了acs bug引起後。觀察v$sql_shared_cursor中大量bind_mismatch，但bind_mismatch根據oracle的規則，隻有5，6種不同的可能性，不至于産生2萬個子遊标。進一不檢視v$sql_bind_capture發現綁定變量值中，出現異常的varchar2類型，且值為空。結合bug 8198150 - high versioncount with bind_mismatch with passing null value to bind (文檔 id 8198150.8)，推斷該sql綁定變量時輸入了空值，導緻産生大量子遊标。在v$sql_bind_capture視圖中表現為varchar2類型（varchar2為oracle預設類型，null值無類型則為oracle預設類型）。
應用做調整限制sql綁定null輸入後，sql正常，無子遊标産生。
處理過程總結
通過故障的情況相關資訊初步推斷為acs（自适應）bug引起。
在關閉acs特性後觀察，sql子遊标和librarycache lock等待事件依然存在。
進步分析并通過測試确認，原因由于sql綁定變量輸入null值觸發bug,導緻會産生大量子遊标，引發library cache lock等待。在應用代碼中将null限制後sql正常
後續工作建議
應用端嚴格限制非合理的綁定變量時null值輸入。
建議給資料庫打上最新psu，避免觸發各bug，提高系統健壯性。