Oracle Shared Pool機制之——Latches, Locks, Pins and Mutexes

1.  Lathes                                                  

  如上場景中，Latches將派上用場。Latches是保護系統全域性區共享資料結構的簡單、低階的序列機制。Latches消除了多程式同時修改共享記憶體時面臨的衝突問題。當伺服器或後臺程式操作或訪問這些共享資料結構時，將會在很短時間內獲取Latches。

 

當Latch被長久持有或Latch需求太高時，就會產生Latch衝突。影響Latch

1)  覆蓋整個庫緩衝的Latches數。如果Latches數較多，那麼，每個Latch保護的雜湊桶數就會更少，當你需要搜尋某個雜湊桶連結串列時與其他使用相同Latch的使用者發生衝突的機率就會少；另一方面，如果系統中有更多的Latches，那麼，系統將會有更多的維護、報告或清理任務要做。

直到Oracle 10g版本，覆蓋庫緩衝的Latches數都非常少。該數目依賴於系統上的CPUs數，應該是與cpu_count引數值相當在，直至最大達到67個Latches。這個數目出奇的小，以至於，即使在系統上執行少量而頻繁執行的不透過語句，即使存取不同的雜湊桶，但可能因為獲取相同Latch而發生Latches衝突。

一旦發現某個物件，我們可以給該物件附加一個KGL Locks（kgllock），從而使得對庫緩衝的搜尋次數最小化，這樣，我們就擁有一個到該物件的捷徑（當開啟/關閉遊標時儲存於PGA中）。當下次同樣的語句釋出時，我們就可以在PGA中找到該物件而不必再搜尋相應的雜湊桶連結串列（軟軟解析）。

我們應該避免長時間持有Latches。這就意味著當我們對已發現的某個記憶體區域做一些耗時處理時，可以將該物件Pin住，以保護我們正使用的記憶體區域，從而我們能釋放相關Latch。

a)  獲取覆蓋相應雜湊桶的Latch；

c)  將該物件Pin住並釋放相應Latch；

e)  獲相應Latch，Unpin該物件並釋放相應Latch；

 

可以透過三種主要方式可以獲取KGL Locks：

2)  使用者可以設定session_cached_cursors引數，以使得Oracle看到使用者使用一條語句多於兩次時，庫緩衝將自動持有相關遊標；

 

除了最小化我們搜尋物件時對庫緩衝的檢索次數外，該Locks還提供如下好處：

2）也被稱為解析（Parse）Locks的庫緩衝Locks用於維護物件及其依賴物件的依賴機制。

5.  為什麼需要庫緩衝Pins（KGL Pins）?

Pin住物件會導致其相關堆被載入進記憶體。如果一個使用者想修改或檢查該物件，則必須獲取Lock後再獲取Pin。

庫緩衝物件上Locks及Pins的相關資訊可透過三個X$表進行查詢，即x$kgllk, x$kglpn和x$kglob.

2）x$kglob包含Locks資源項；

 

庫緩衝鎖及釘住（Locking和Pinning）機制也許會導致兩個問題。

 KGL Locks及Pins相關的另一個問題是，當使用它們時，必須頻繁的建立記憶體區域，標明屬性，將它們插入連結串列（或移出連結串列並將其放回共享池），期間，這些操作需要一直持有獨佔模式的Latch，對繁忙的系統來說，整個庫緩衝Locks及Pins將帶來很大威脅。

 

為了改善遊標的執行和硬解析，Oracle 10gR2版本引入了一個新的、更好粒度的記憶體序列機制。對某些共享遊標相關的操作，Mutexes（Mutual exclusion objects，互斥物件）可用來替代庫緩衝Latches和庫緩衝Pins。Mutex工作方式與Latch基本相同，但操作Mutexes的程式碼路徑更短，更輕量級，通常也會被硬體直接支援。因此，與Latch機制相比，Mutexes會更快，耗費更少的CPU，併發性方面也會有很大提升。32位Linux系統上，常規Latch結構佔用110位元組，而Mutex僅佔28位元組。而Mutex消耗的指令也更少。獲取一個Latch需要消耗150~200個指令，而獲取一個Mutex則只需大約30-35個指令。

 

Mutexes可以共享或獨佔模式獲取，也可以等待或非等待模式完成。

2）替換Latches和Pins：Mutexes具有雙重性。其可以作為一種序列機制（像一個Latch），同時也可以作為一個Pin（例如：阻止物件從記憶體中被移除）。 一個Latch不能被多個會話同時獲取，而一個Mutex可以被多個會話同時參考，多個會話可以共享模式參考該Mutex。以共享模式參考一個Mutex的總會話數被稱為參考數（Ref Count）。一個Mutex的參考數被儲存於其自身。一個Mutex也可以獨佔模式被一個會話持有。

除了每個子游標控制程式碼中有Mutex結構且其作為遊標Pin結構而帶來的主要好處。如果你正有一個遊標被開啟（或在會話遊標緩衝內），你不必獲取庫緩衝Latch（而之前為了改變遊標Pin狀態而必須這麼做），就可以直接修改遊標Mutex的參考數（透過會話UGA內開啟遊標狀態區域的指標）。

 

1) 庫緩衝Latch機制在解析等操作中依然被需要，Mutexes僅僅解決了庫緩衝的Pin問題。

3)由於Mutexes是一種通用機制（而非庫緩衝專用），其也被用於V$SQLSTATS底層結構。

5）Latches和Mutexes為獨立的機制，即一個程式可以同時持有Latch和Mutex。Oracle10.2.0.2以上的版本中，只要“_kks_use_mutex_pin”引數被開啟，庫緩衝Pin Latch將被Mutex替代，同時，其他一些類似V$SQLSTATS陣列及父遊標檢查的操作也被Mutexes保護。然而，使用kksfbc()的真正子游標查詢依然被庫緩衝Latches保護，但是，頻繁軟解析加上很少的遊標緩衝及較長的庫緩衝雜湊鏈將導致這些Latches成為一個問題（記住，即使在普通的雜湊鏈掃描中，庫緩衝Latch始終被以獨佔方式獲取）。

Oracle 11g版本中，有另外一些Mutexes，其中最重要的一個是庫緩衝Mutex。同時，除了“library cache load lock”外，所有庫緩衝相關的Latches都消失了，取而代之，相應操作都被Mutexes保護。“libarary cache”Latches已被“library cache”Mutexes替代。

librarycache pin allocation

librarycache hash chains

librarycache

而Oracle 11g版本中僅剩的Latches為：

下列出現於Oracle 10g版本的與庫緩衝相關的等待事件在Oracle 11g版本中也不復存在：

latch:library cache lock

Oracle 11g版本中與庫緩衝相關的等待事件為：

librarycache lock

librarycache: mutex X

OSD IPClibrary

librarycache shutdown