模板
教程
環境
性能
功能
管理
深入理解Oracle中的Mutex(4)
若Holder id已被設置，則申請進程將可能進入等待事件 。 例如若當前Mutex的持有者進程正以X mode更新該Mutex，則申請者的等待事件應為”cursor: pin S on X” 。 而若當持有者Holder并不是”真的要持有” 該Mutex，而僅僅是嘗試更新其Ref Count,則第二個進程將等在’ Cursor :pin S’等待事件上; 實際正在更新Ref count的操作時很快的，是一種輕微的操作。 當第一個進程正在更新mutex，則后續的申請進程將進入spin 循環中255次等待前者結束。 當mutex上不再有 Holder id時(如前者的進程已經更新完Ref Count)時， 則申請者進程將Holder ID設為自身的SID，并更新Ref Count，并清除Holder id。 若在255次循環SPIN后mutex仍不被釋放，則該進程進入等待并不再跑在CPU上。
Mutex相關的等待事件
cursor: mutex * events等待事件
cursor: mutex * events等待事件用于Cursor Parent 和 Cursor stats類型的操作：
‘cursor: mutex X’ ， 某個進程申請以EXCL mode持有mutex時進入該等待， 該Mutex要么正被其他進程以SHRD模式參考，這導致X mode的申請必須要等待直到Ref count=0， 或者該mutex正被另一個進程以X mode持有。
相關操作要求以EXCL X mode持有Mutex的：
在一個父游標下創建一個新的子游標
捕獲SQL中的綁定變量
更新或構件SQL統計信息V$SQLSTATS
‘Cursor: Mutex S’ ， 某個進程以SHRD S mode申請一個Mutex， 而該Mutex要么被其他進程已EXCL X mode所持有，要么其他進程正在更新mutex 上的Ref Count。
相關類型的操作一般是檢測父游標或者CURSOR統計信息數據， 此外查詢V$SQLSTATS也會造成CURSOR statistics被查詢
‘cursor: pin * events’等待事件
該類等待事件一般是為了pin相關的子游標
cursor: pin S 當一個進程以共享pin模式申請一個Mutex，而不能立即獲得時，進入cursor: Pin S等待事件。 Mutex Pin是以共享類型的操作，例如執行一個游標。
當一個進程等在cursor: pin S上，說明該進程在對一個共享的mutex pin 參考或取消參考時，有其他的進程也正在為同樣的cursor heap創建或者取消一個共享Mutex pin。 實際上cursor: pin S 等待事件應當很少見，因為更新共享Mutex pin 的reference 應當是很快的。 再重復一次，S mode的Mutex可以被并發持有， 但是更新Mutex的Ref Count仍需要串行地處理 。 一旦reference count被增加好，則后續進程將可以為同樣的cursor heap增加reference count。 因此此處mutex 即可以扮演Latch的角色(串行控制ref count的更新)，又可以扮演pin的角色(ref count本身)。
‘cursor: pin X’ 當一個進程需要以EXCL X mode獲得mutex時， 這類需要EXCL X 模式的串行操作包括:
構建一個子游標
某個進程已經以X mode持有該Mutex
一個或多個進程正在reference 該Mutex (shared mutex pin)
‘Cursor: pin S on X’ 最常見的等待事件， 進程為了共享操作例如執行pin游標而以SHRD S mode申請mutex， 但是未立即獲得。原因是該游標被其他進程以EXCL X mode 持有了。
Mutex的相關統計視圖
V$MUTEX_SLEEP
shows the wait time, and the number of sleeps for each combination of mutex type and location.
| Column | Datatype | Description |
|---|---|---|
| MUTEX_TYPE | VARCHAR2(32) | Type of action/object the mutex protects |
| LOCATION | VARCHAR2(40) | The code location where the waiter slept for the mutex |
| SLEEPS | NUMBER | Number of sleeps for this MUTEX_TYPE and LOCATION |
| WAIT_TIME | NUMBER | Wait time in microseconds |
V$MUTEX_SLEEP_HISTORY
displays time-series data. Each row in this view is for a specific time, mutex type, location, requesting session and blocking session combination. That is, it shows data related to a specific session (requesting session) that slept while requesting a specific mutex type and location, because it was being held by a specific blocking session. The data in this view is contained within a circular buffer, with the most recent sleeps shown.
| Column | Datatype | Description |
|---|---|---|
| SLEEP_TIMESTAMP | TIMESTAMP(6) | The last date/time this MUTEX_TYPE and LOCATION was slept for by theREQUESTING_SESSION, while being held by the BLOCKING_SESSION. |
| MUTEX_TYPE | VARCHAR2(32) | Type of action/object the mutex protects |
| GETS | NUMBER | The number of times the mutex/location was requested by the requesting session while being held by the blocking session. GETS is only incremented once per request, irrespective of the number of sleeps required to obtain the mutex. |
| SLEEPS | NUMBER | The number of times the requestor had to sleep before obtaining the mutex |
| REQUESTING_SESSION | NUMBER | The SID of a session requesting the mutex |
| BLOCKING_SESSION | NUMBER | The SID of a session holding the mutex |
| LOCATION | VARCHAR2(40) | The code location where the waiter slept for the mutex |
| MUTEX_VALUE | RAW(4) | If the mutex is held in exclusive (X) mode, this column shows the SID of the blocking session, else it shows the number of sessions referencing the mutex in S mode. |
| P1 | NUMBER | Internal use only |
| P1RAW | RAW(4) | Internal use only |
| P2 | NUMBER | Internal use only |
| P3 | NUMBER | Internal use only |
| P4 | NUMBER | Internal use only |
| P5 | VARCHAR2(64) | Internal use only |
原文轉自：http://blogread.cn/it/article/6410
