深入理解Oracle中的Mutex

　　雖然Mutex中文翻譯為互斥鎖，但為了和OS mutex充分的區別，所以我們在本文里稱Oracle Mutex為Mutex。

　　Oracle中的mutex，類似于Latch，是一種低級的串行機制，用以控制對SGA中部分共享數據結構的訪問控制。 Oracle中的串行機制有不少，引入它們的目的是避免一個對象出現下述現象：

　　當某些進程在訪問該對象時，該資源被重新分配

　　當某些進程在修改它時，被其他進程讀取

　　當某些進程在修改它時，被其他進程修改

　　當某些進程在讀取它時，被其他進程修改

　　不同于Latch，Mutex的使用更靈活，用途更多，例如:

　　哪些需要被mutex保護的共享數據結構可以有自己獨立的mutex，即一個對象擁有自己獨立的mutex，不像Latch往往一個需要保護大量對象，舉例來說，每一個父游標有其對應的mutex， 而每一個子游標也有其對應的mutex

　　每一個數據結構可能有一個或多個mutex保護，每一個mutex負責保護其結構的不同部分

　　當然一個mutex也可以用來保護多于一個的數據結構

　　理論上mutex即可以存放在其保護的結構本身中(其實是嵌入在結構里)，也可以存放在其他地方。 一般情況下Mutex是在數據結構需要被保護時動態創建出來的。 如是嵌在需要保護結構體內的mutex，則當 所依附的數據結構被清理時 該mutex也將被摧毀。

　　Mutex帶來的好處

　　雖然mutex和latch都是Oracle中的串行機制，但是mutex具有一些latch沒有的好處

　　更輕量級且更快

　　Mutex作為Latch的替代品，具有更快速獲得，更小等優勢。 獲取一個mutex進需要大約30~35個指令， 而Latch則需要150~200個指令。一個mutex結構的大小大約為16 bytes，而在10.2版本中一個latch需要112個bytes，在更早的版本中是200個bytes。 從200個bytes 精簡到112個是通過減少不必要的統計指標 SLEEP1~SLEEP11、WAITERS_WOKEN, WAITS_HOLDING_LATCH等從而實現的。今后我們將看到更多關于Latch的代碼優化。

　　減少偽爭用

　　典型情況下一個Latch保護多個對象。 當一個Latch保護多個熱對象時，并行地對這些對象的頻繁訪問讓latch本身變成性能的串行點。 這也就是我們此處說的偽爭用點， 因為爭用是發生在這個串行保護的機制上，而不是進程去訪問的對象本身。與latch不同， 使用mutex的情況下Oracle開發人員可以為每一個要保護的數據結構創建一個獨立的mutex。 這意味著Latch的那種偽爭用將大大減少，因為每一個對象均被自己獨立擁有的mutex保護

　　Mutex在一些地方替代了latch和PIN

　　一個Mutex可供多個Oracle進程并行地參考，反過來說進程們可以以S(Shared 共享) mode模式參考一個Mutex。以S mode一起共享參考這個mutex的進程的總數成為參考總數reference count。Mutex自身結構中存放了這個ref count的數據。另一方面，mutex也可以被以X (Exclusive)mode排他模式被僅有一個進程所持有Held。

　　Mutex有2種用途，一方面他們可以充當維護必要串行機制的結構，如同latch那樣; 同時也可以充當pin，避免對象被age out。

　　舉例來說，mutex結構中包含的ref count信息可以用作替代library cache pin。 在mutex充當cursor pin之前，當一個進程要執行=>pin一個cursor時需要做的是針對性地創建library cache pin和刪除這個library cache pin(均為S mode)。mutex充當cursor pin之后，進程只需要增加和減少mutex上的ref count即可。

　　當某一個進程首次解析一個游標 Cursor，他將臨時創建并移除一個library cache pin，但是該進程后續的解析或執行進要求增加或者減少ref count。注意在這個增加/減少ref count的過程中無需acquire latch，這是因為mutex自身能起到限制串行訪問修改ref count的作用。 當一個進程要移除自己的mutex pin時，它減少ref count，同樣的無需acquire 任何latch。

　　Mutex和Latch的交互

　　Latches和Mutex 是獨立的串行機制， 舉例來說一個進程可以同時持有latch和mutex。 在進程異常dead的情況下，一般latch要比Mutex更早被PMON清理。 一般情況下不存在mutex的死鎖。 不像latch，在早期版本例如9i之前我們經常遇到latch死鎖的問題。

　　Mutex的用途

　　在版本10.2中僅僅有 KKS 這個內核層是mutex的客戶，KKS 意為 Kernel Kompile Shared， 它是Library Cache中的shared cursor游標共享部分層次的代碼。 在之后的版本中，ORACLE開發部門更多地使用了Mutex，不局限于KKS。

　　KKS游標共享如何使用Mutex

　　kks 使用mutex以便保護對于下述基于parent cursor父游標和子游標child cursor的一系列操作。

　　對于父游標parent cursor的操作：

　　基于發生的不同操作，對應不同的等待事件：

　　在某個父游標名下創建一個新的游標 ==> cursor:mutex X

　　檢查一個父游標 ==> cursor:mutex S

　　綁定值捕獲 ==> cursor:mutex X

　　保護父游標的mutex嵌入在父游標結構內

　　針對父游標parent cursor的Mutex類型為’Cursor Parent’ (kgx_kks2).

　　針對父游標parent cursor的Mutex等待事件均為’ Cursor: mutex *’的形式

　　針對游標統計信息的操作

　　基于對不同的游標統計信息的操作有不同的等待事件：

　　構造，更新游標相關的統計信息 ==> cursor:mutex X

　　檢測游標相關的統計信息，例如訪問V$SQLSTATS ==> cursor : mutex S

　　相關的游標可能在父游標中，也可能在游標統計信息相關的hash table上

　　針對游標統計信息的Mutex類型為Cursor Stat (kgx_kks1)

　　針對游標統計信息的Mutex等待事件均為’ Cursor: mutex *’的形式

　　Mutex是如何替代library cache pin來保護cursor heap的?

　　傳統的’library cache pin’在10.2.0.2之后默認被取代， 此處PIN被Mutex及其ref count取代。 當進程執行游標語句時或者需要PIN，或者需要hard parse一個子游標heap。

原文轉自：http://blogread.cn/it/article/6410