深入理解Oracle中的Mutex(2)

　　在版本10.2.0.1中， 使用mutex部分代碼替代PIN的功能默認是不激活的，實際上這取決于隱藏參數_KKS_USE_MUTEX_PIN，在10.2.0.2之后_KKS_USE_MUTEX_PIN默認為TRUE。 換而言之在版本10.2中我們還是可以關閉KKS使用MUTEX替代PIN保護CURSOR的， 但是在版本11g中則幾乎無法關閉MUTEX。 注意10.2中僅當KKS真正使用MUTEX時，library cache pin不再用作cursor pin。

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

　　為執行某個SQL而PIN一個游標Cursor ==>Cursor: Pin S Wait on X

　　當執行一個游標而PIN Cursor，而該Cursor正被其他進程以S mode檢測 ==> cursor:pin S

　　當試圖重建一個游標Cursor ==> Cursor: pin X 該等待事件一般不太會看到，因為當一個游標正被執行，且其需要重建時會有另一個游標被創建

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

　　Mutex類型為’Cursor Pin’ (kgx_kks3)

　　等待事件均為 ‘cursor: pin *’的形式

　　KKS使用MUTEX情況下SQL語句的 解析與執行的收益

　　在版本10.2中， 以下是幾個SQL解析與執行從MUTEX哪里獲得主要收益：

　　在某個父游標下構建一個新的子游標

　　首先這種構建新子游標的操作更廉價了， 當時Maclean仍要告誡你 一個父游標下過多的子游標仍不是一件好事情

　　對父游標的檢測

　　在找到一個合適的游標并執行前，父游標需要被適當檢測。 對父游標的這種檢測目前也使用mutex來保護了，所以這種檢測更的成本更低了

　　對于已經加載在Library Cache 中的SQL語句重復執行

　　常規情況下，當一個進程要執行SQL游標前總是必須要先pin它

　　不使用MUTEX的情況：若游標處于OPEN狀態下以便今后的重復執行，且參數cursor_space_for_time(CSFT 目前已不推薦使用該參數)為TRUE，則每一次重復執行可以不需要library cache pin。 若游標處于OPEN狀態下但是cursor_space_for_time=false，則進程在重復執行SQL游標前總是要先拿library cache pin

　　使用MUTEX的情況: 相反，若使用mutex來替代library cache pin時，則無需關心cursor_space_for_time 。 僅第一個進程需要做一個PIN，其他后續進程都只需要簡單地在對應保護cursor heap的mutex上拿一個共享reference 。

　　查詢SQL統計信息

　　通過V$SQLSTAT視圖(本質上是X$KKSSQLSTAT)訪問SQL統計信息時，其所需要的CPu和獲取的Latch數量要遠遠少于訪問其他V$SQL視圖。 在早期版本中, 并行地訪問V$SQL或者V$SQLAREA視圖會造成 library cache latch的爭用。

　　Mutex 的統計信息

　　下面是一個AWR中的Mutex Sleep Statistics， 這些數據主要來源于V$MUTEX_SLEEP視圖。

　　Mutex Sleep Summary

　　ordered by number of sleeps desc

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