library cache lock等待事件的概述：
- library cache lock 是在爭搶library cache中的資源而造成的資源等待，它有3個引數：p1 物件的地址；p2 鎖的地址； p3 namespace等，確定是表、包、索引等。
- 對這個lock的等待，pmon是1秒，其它程式都是3秒
- 出現這個等待時，經常表現的症狀是：我們無法進行一些查詢，甚至不能desc table_name來檢視某個內容。由於等待資訊不出現在v$lock中，所以，我們根據v$lock不能夠確定其中的原因
解決library cache lock的方法：
- analyze system state dump： 我們可以透過systemstate事件，來檢視所有oracle 程式的資訊。這些資訊當中包括某個特殊程式的請求/等待資源的資訊
ALTER SESSION SET EVENTS 'IMMEDIATE TRACE NAME SYSTEMSTATE LEVEL 10'; 我們到trace檔案中，去查詢等待程式的pid，觀看該程式的等待資訊：
PROCESS 8:
----------------------------------------
SO: 50050b08, type: 1, owner: 0, flag: INIT/-/-/0x00
(process) Oracle pid=8, calls cur/top: 5007bf6c/5007bf6c, flag: (0) -
int error: 0, call error: 0, sess error: 0, txn error 0
(post info) last post received: 82 0 4
last post received-location: kslpsr
last process to post me: 5004ff08 1 2
last post sent: 0 0 13
last post sent-location: ksasnd
last process posted by me: 5004ff08 1 2
(latch info) wait_event=0 bits=0
Process Group: DEFAULT, pseudo proc: 50058ac4
O/S info: user: daemon, term: pts/1, ospid: 15161
OSD pid info: 15161
----------------------------------------
SO: 5005f294, type: 3, owner: 50050b08, flag: INIT/-/-/0x00
(session) trans: 0, creator: 50050b08, flag: (41) USR/- BSY/-/-/-/-/-
DID: 0001-0008-00000002, short-term DID: 0000-0000-00000000
txn branch: 0
oct: 6, prv: 0, user: 41/LC
O/S info: user: daemon, term: pts/1, ospid: 15160, machine: goblin.forgotten.realms
program: sqlplus@goblin.forgotten.realms (TNS V1-V3)
application name: SQL*Plus, hash value=3669949024
waiting for 'library cache lock' blocking sess=0x0 seq=253 wait_time=0
!>> handle address=5023ef9c, lock address=5019cad4, 10*mode+namespace=15
Using the 'handle address' you can look up the process that is keeping a lock
on your resource by doing a search on the address within the same tracefile.
Example output:
PROCESS 9:
----------------------------------------
SO: 50050e08, type: 1, owner: 0, flag: INIT/-/-/0x00
(process) Oracle pid=9, calls cur/top: 5007bbac/5007bbfc, flag: (0) -
int error: 0, call error: 0, sess error: 0, txn error 0
----------------------------------------
SO: 5019d5e4, type: 34, owner: 5015f65c, flag: INIT/-/-/0x00
!>> LIBRARY OBJECT PIN: pin=5019d5e4 handle=5023ef9c mode=X lock=0
user=5005fad4 session=5005fad4 count=1 mask=0511 savepoint=118218 flags=[00]
這樣我就可以看到，pid 9 以獨佔方式鎖住了一個資源，而pid 8在等待。那我們就可以根據v$process、v$session來查詢該session的情況，必要時可以殺掉
- 檢查X$KGLLK 系統表 該系統表顯示的是所有請求/持有 library cache lock的session資訊，比v$lock表的資訊要詳細很多。該表的主要欄位含義如下： KGLLKSES session的id號； KGLNAOBJ object的名稱； KGLLKHDL object的實體地址；KGLLKREQ 請求它持有鎖的數量； 我們可以獲得所有的堵塞程式，從而可以殺掉他們：
In the same way we can also find all the blocked sessions:
SELECT SID,USERNAME,TERMINAL,PROGRAM FROM V$SESSION
WHERE SADDR in
(SELECT KGLLKSES FROM X$KGLLK LOCK_A
WHERE KGLLKREQ > 0
AND EXISTS (SELECT LOCK_B.KGLLKHDL FROM X$KGLLK LOCK_B
WHERE KGLLKSES = 'saddr_from_v$session' /* BLOCKING SESSION */
AND LOCK_A.KGLLKHDL = LOCK_B.KGLLKHDL
AND KGLLKREQ = 0)
);
一個解決案例：
- 使用者報desc table_name 出錯，所有跟該表有關係的語句都不能執行
- 檢視系統的鎖資訊，沒有任何資訊：select * from v$lock where block=1;
- 查詢v$session_wait發現32號session有大量的 library chace lock 等待事件
- 對32號session 進行跟蹤：exec dbms_system.set_ev(32,27506,10046,12,'');
- 檢視那些表被那些sid鎖住了：select * from v$lock_object;
- 根據5步獲得的sid，獲得鎖住object的pid
- 殺掉6步獲得的pid
- 發現是使用TOAD工具，該工具在瀏覽系統結構，並且長時間inactive而造成的