LIBRARY CACHE LOCK 等待事件

接下篇日誌，如果此時再發出一條grant或compile的命令，那麼library cache lock等待事件將會出現。

Session 3：
sys@NEI> alter procedure pining compile;

此程式掛起，查詢v$session_wait檢視可以獲得以下資訊：

sys@NEI> select * from v$session_wait where event like 'library cache%';

       SID       SEQ# EVENT                P1TEXT             P1 P1RAW    P2TEXT             P2 P2RAW    P3TEXT     P3
---------- ---------- -------------------- ---------- ---------- -------- ---------- ---------- -------- ---------- ----------
P3RAW    WAIT_CLASS_ID WAIT_CLASS# WAIT_CLASS       WAIT_TIME SECONDS_IN_WAIT STATE
-------- ------------- ----------- --------------- ---------- --------------- -------------------
       142         33 library cache lock   handle add 1042613708 3E2505CC lock addre 1090222084 40FB7804 100*mode+n          301
                                           ress                           ss                             amespace
0000012D    3875070507           4 Concurrency              0             174 WAITING

       153         33 library cache pin    handle add 1042613708 3E2505CC pin addres 1093359824 412B58D0 100*mode+n          301
                                           ress                           s                              amespace
0000012D    3875070507           4 Concurrency              0             210 WAITING

由於handle上的lock已經被Session 2以exclusive模式持有，所以Session 3產生了等待。可以看到，在生產資料庫中許可權的授予、物件的重新編譯可能會導致library cache pin等待的出現，所以應該儘量避免在高峰期進行以上操作。

另外，測試的案例本身就說明：如果Package或過程中存在複雜、互動的依賴關係極易導致library cache pin的出現，所以在應用開發的過程中，也應該注意這方面的內容。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/8183550/viewspace-659592/，如需轉載，請註明出處，否則將追究法律責任。