【故障現象】
某些session執行操作被堵塞，檢查event發現’library cache lock/pin’等待；
【可能故障原因】
library cache lock/pin發生在多個session對相同library cache對象進行爭用發生，一般來說在存儲過程編譯過程中發生并堵塞編譯。
【應急措施】
堵塞和被堵塞session在同一個實例上：
查找導致library cache lock/pin的對象；
SELECT KGLNAOWN,KGLNAOBJ
FROM x$kglob
WHERE kglhdadr in(
select P1RAW from v$session_wait where event like 'library cache%');
繼續查找那些session導致了library cache lock/pin等待：
select sid, serial#,program ,machine from v$session
where paddr in (
SELECT s.paddr FROM x$kglpn p, v$session s
WHERE p.kglpnuse=s.saddr(+) AND p.kglpnmod <> 0 and kglpnhdl in (
select p1raw from v$session_wait
where event in ('library cache pin','library cache lock' ,'library cache load lock')));
注： 如果上述SQL時間執行時間較長，可手動分步執行，如先執行IN中的子SQL。
根據實際情況嚴重程度進行如下緊急處理：
a)對所有導致library cache lock/pin的session進行kill，解決堵塞情況。
堵塞和被堵塞session不在同一個實例上：
查找導致library cache lock/pin的對象；（同情況1）
SELECT KGLNAOWN,KGLNAOBJ
FROM x$kglob
WHERE kglhdadr in(
select P1RAW from v$session_wait where event like 'library cache%');
在其他實例上陸續進行查找導致了library cache lock/pin等待的session，首先確認其他實例上的堵塞對象的地址，參考上面查詢結果：
select sid, serial#, sql_text from dba_kgllock w, v$session s, v$sqlarea a
where w.kgllkuse = s.saddr and w.kgllkhdl in(
select kglhdadr from x$kglob where kglnaown='SYS' and kglnaobj = 'DUMMY')
and s.sql_address = a.address
and s.sql_hash_value = a.hash_value;
根據實際情況嚴重程度進行如下緊急處理：
a)對所有導致library cache lock/pin的session進行kill，解決堵塞情況。
注意在os級別kill之前，先用ps命令查看一下該進程，如果是DB進程，不可隨意kill，否則會導致系統crash
【后續分析】
此類問題主要是由于并發執行對象編譯導致的，解決思路就是將編譯動作串行執行，減少并發爭用。同時，后續需要查詢此類操作為什么發起，在業務高峰期應當避免。
)
