模板
教程
環境
性能
功能
管理
深入理解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
| Mutex Type | Location | Sleeps | Wait Time (ms) |
|---|---|---|---|
| Library Cache | kglhdgh1 64 | 2,356 | 0 |
| Library Cache | kglpnal2 91 | 2,345 | 0 |
| Cursor Pin | kkslce [KKSCHLPIN2] | 2,084 | 0 |
| Library Cache | kglpin1 4 | 956 | 0 |
| Library Cache | kglhdgn2 106 | 784 | 0 |
| Library Cache | kglpndl1 95 | 691 | 0 |
| Library Cache | kglpnal1 90 | 605 | 0 |
| Library Cache | kgllkdl1 85 | 580 | 0 |
| Library Cache | kgllkal1 80 | 404 | 0 |
| Library Cache | kglllal3 111 | 282 | 0 |
| Library Cache | kglllal1 109 | 218 | 0 |
| Library Cache | kglhdgn1 62 | 163 | 0 |
| Library Cache | kgllldl2 112 | 156 | 0 |
| Library Cache | kgllkc1 57 | 105 | 0 |
| Library Cache | kglget2 2 | 100 | 0 |
| Library Cache | kglini1 32 | 53 | 0 |
| Library Cache | kglget1 1 | 31 | 0 |
| Cursor Pin | kksLockDelete [KKSCHLPIN6] | 22 | 0 |
| Library Cache | kgllkal3 82 | 18 | 0 |
| Library Cache | kglUnsetHandleReference 120 | 10 | 0 |
| Cursor Pin | kksxsccmp [KKSCHLPIN5] | 10 | 0 |
| Library Cache | kglobld1 75 | 8 | 0 |
| Cursor Pin | kksfbc [KKSCHLPIN1] | 8 | 0 |
| Library Cache | kglUpgradeLock 119 | 7 | 0 |
| Library Cache | kglhdgc1 102 | 2 | 0 |
| Cursor Pin | kksfbc [KKSCHLFSP2] | 2 | 0 |
| Library Cache | kgldtin1 42 | 1 | 0 |
| Library Cache | kglhbh1 63 | 1 | 0 |
| Library Cache | kgllkal5 84 | 1 | 0 |
| Library Cache | kglrdtin1 44 | 1 | 0 |
| Cursor Parent | kkscsPruneChild [KKSPRTLOC35] | 1 | 0 |
原文轉自：http://blogread.cn/it/article/6410
