模板
教程
环境
性能
功能
管理
深入理解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
