深入理解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