【ASK_ORACLE】Library cache pin 與 library load lock的關係和區別

Library cache pin 與 library load lock 關係和區別

Library cache pin 和 load lock 可能出現在對 PL/SQL, views, types 等的編譯與重編譯期間。這種編譯總是顯式的(比如應用安裝，升級，打補丁)。但是物件重編譯也可能發生在物件失效期間。

 

在處理那些讓人摸不著頭腦的 library cache pin 和 load lock 等待時，則需要檢查為什麼物件失效了。很有可能失效是由於某些操作修改了它所依賴的物件的"LAST_DDL"。通常來說這些操作包括物件維護操作，比如 ALTER, GRANT, REVOKE, replacing views 等等。還有就是收集 optimizer statistics 也會造成 cursor 失效，進而導致 library cache 的重灌載。這個現象在 Oracle Server Application Developer's Guide 的object dependency maintenance 部分有描述。

 

物件失效以後，Oracle 嘗試在第一次訪問這個物件時去重編譯它。有些情況下，如果其它 session 已經 pin 住這個物件，可能就會出現問題。並且在有大量活躍使用者與複雜依賴關係(例如，很多交叉依賴的 packages 或package bodies)的情況下更容易出現問題。有些時候對物件的編譯會持續數小時從而阻止其它 session 對其的訪問。

在 library cache dump, level 10 可以看到:

查詢 ALTER ... COMPILE 語句和 lock=X 或 pin=X 的 objects/handles.

 

特別注意：

1. 需要頻繁使用的 stored PL/SQL 所依賴的物件，對其 altering, granting, evoking 操作需要特別小心。實際上，解決這種問題很大程度上依賴於應用程式和系統維護的時間。應用程式開發者需要考慮某些決定可能會對應用程式的可擴充套件性及效能產生負面影響。

 

2. Load lock總是以排它模式獲得的。如果 session load lock 繁忙，session 將一直等待，直到鎖變成可用。