enq：Library cache lock/pin等待事件

這個事件控制對 library cache 的併發使用。 它獲取一個物件控制程式碼（object handle）上的鎖，從而：

• 一個使用者可以防止其它使用者訪問同一個物件。

• 這個使用者可以長時間地維護一個依賴物件(例如，其它使用者不能更改這個物件)。

定位 library cache 中的一個物件同樣也需要這個鎖。
在解析或編譯 SQL 或 PL/SQL 語句期間，我們需要獲得被引用的資料庫物件(表，檢視，過程，函式，包，包體，觸發器，索引，聚簇，同義詞)的 library cache lock；這個鎖在解析與編譯結束時會被釋放。

cursor(SQL 與 PL/SQL 區)，管道（pipes）和其它的瞬時（transient）物件不使用這個鎖。

Library cache lock 上的死鎖不會被自動檢測到，對其的操作是同步進行的。

引數:

• handle address：物件地址；
• lock address：鎖地址。它與 latch 與 enqueue 不同，它是一個 State Object；
• Mode：申請鎖的級別；
• Namespace：物件使用的 namespace, 取自於 V$DB_OBJECT_CACHE。

這個事件管理 library cache 併發。Pin 住一個物件會使它使用的 heap 被載入到記憶體中。如果一個使用者想要修改或檢查這個物件，它必須在獲得 lock 之後再取得一個 pin。Pin 可以用 NULL, SHARE, EXCLUSIVE 模式獲得，並且可以看做是一種特殊的 lock。等待"library cache pin"意味著這個 PIN 正被某個其它 session 以不相容的模式持有。
訪問當前被快取到 library cache 中的資料庫物件（表，檢視，過程，函式，包，包體，觸發器，索引，聚簇，同義詞）的時候需要獲得 library cache pin; 在 library cache 中，資料庫物件被快取成兩部分：控制程式碼(handle)和物件(object); 這個鎖（pin）是用來保護"object"部分的。
Library cache pin 上的死鎖不會被自動檢測到，對其的操作是同步進行的。
注意：在10g以後，"library cache pin"已經被 mutex 取代。
參見：Note 1298015.1 WAITEVENT: "cursor: pin S wait on X" Reference Note

       Lock 與 pin 都用於訪問在 library cache 中的物件。Lock 管理不同程式間的併發，pin 則管理緩衝區的一致性。為了訪問一個物件，程式必須首先鎖定（lock）這個物件的控制程式碼(handle)，然後它自己 pin 住物件的記憶體堆。Lock 與 pin 請求會一直等待直到獲得為止，這是一個引起爭用的可能的原因，因為它沒有 NOWAIT 請求模式。通過獲得一個在物件控制程式碼上的鎖，一個程式能防止其它程式訪問這個物件，甚至不可以檢視它的型別。它還能在維護物件依賴關係的同時不阻止其它程式訪問這個物件。獲取一個 lock 同樣也是在快取中查詢物件的唯一途徑。查詢並鎖住物件是在一個操作中完成的。如果一個程式想檢查或修改一個物件，那麼它必須獲得一個在這個物件上的 pin (獲得了在控制程式碼上的鎖之後)。Pin這個動作會將相應物件的資訊載入到記憶體，如果之前沒有的話，同時還能確保這些資訊保留在記憶體直到 pin 被釋放。

       Oracle 在分析/編譯 Package/Procedure/Function/View 時需要 Library Cache Lock 和 Library CachePin。這是為了確保在分析/編譯期間, 沒有其它人可以對這些物件的定義進行改變，或者刪除、重建這個物件。

當一個 SQL 語句被一個 session 硬解析時，這個 session 需要獲得一個 library cache lock 以便阻止其它 session 去訪問或修改同一個物件。如果這個事件等待很長時間。這表明可能 shared pool 過小或經常

發生物件被 flush 出去的清醒。還有，這表明資料庫物件被經常修改。除了硬解析，如果一個 session 要更改被 SQL 語句引用的物件的定義或對其做任何更改，就必須獲得一個library cache lock 和 library cache pin。需要 Pin 的原因是需要載入資料字典資訊到記憶體中來修改這個物件。

我們首先要確認的是 library cache 的競爭是整個系統層面的還是隻發生在某個或某些 SQL 語句上。這個"library cache lock"是被一個特定的 SQL 持有很長的時間嗎？或者總是在等待某個特定的物件？還是說這個鎖在短時間內被請求的次數很多從而造成的競爭？
如果問題是在整個系統層面發生的，一般來說是由於 shared pool 太小或 SQL 語句不共享造成的。一些解決競爭的方法：

• 增大 shared pool 從而減少 reload 的次數，這是因為 shared pool 過小會造成獲取鎖的時間加長。
• 通過將 cursor_sharing 設定為 similar 或 force 來使 SQL 語句共享。（需要小心的是這樣做可能會改變SQL的執行計劃，所以做之前需要做完整的測試）
• 在系統不繁忙的時候做統計資訊的收集或其它維護作業，從而降低無效化（invalidation）的次數。

如果您發現是某條或某些SQL產生的問題，那麼需要檢查為什麼它持有鎖的時間會那麼長。

https://support.oracle.com/epmos/faces/DocumentDisplay?parent=DOCUMENT&sourceId=1548524.1&id=122793.1

如果"library cache pin"等待的時間很長那麼很重要的一點就是判斷是隻有一兩個 process 在等待還是有很多的 process 都在等待。

• 如果說只是一兩個 process 被另一個 process 阻塞的話，那麼需要檢查持有這個 pin 的process 為什麼這麼長時間不釋放。
• 如果說等待是大範圍的那麼說明 shared pool 需要優化。

https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=201008601673047&parent=DOCUMENT&sourceId=1548524.1&id=62143.1&_afrWindowMode=0&_adf.ctrl-state=12aq9613b9_94