cursor: pin S wait on X

‘cursor: pin * events’等待事件

该类等待事件一般是为了pin相关的子游标

‘Cursor: pin S on X’ 最常见的等待事件， 进程为了共享操作例如执行pin游标而以SHRD S mode申请mutex， 但是未立即获得。原因是该游标被其他进程以EXCL X mode 持有了。

实际该 cursor: pin S wait on X等待事件往往是由于其他因素诱发的。Mutex争用仅仅是问题的症状，但根本原因需要Database Consultant 进一步挖掘。


下面我们列出一些已知的常见案例， 在这些例子中可以看到 我上面提到的 Mutex的争用仅仅是伪争用:


过多的子游标 High Version Counts


过多的子游标版本Version Count可能导致Mutex 争用，一般一个SQL的Version Count不要高于500。

检查High Version Count很简单， 在AWR里就有SQL ordered by High Version Count，也可以写SQL查V$SQL、V$SQLAREA



昂贵的X$、V$视图查询


一些对于V$、X$视图的查询，需要访问X$KGL*之类的fixed table，可能触发Mutex争用。

Mutex持有者得不到CPU


Mutex持有者若得不到足够的CPU片可能一直阻塞他人，直到它拿到需要的CPU。

这种情况可能由于OS操作系统的实际情况或者使用Resource Manager而引起。需要配合AWR中的Host CPU、Instance CPu一起看。


已经被KILLED的SESSION仍持有Mutex

当session正持有Mutex，而其对应的Process被强制KILL掉， 则直到PMON彻底清理掉该Dead Process并释放Mutex，其他session才能不再等待。 诊断该类问题，最好能检查PMON的TRACE。 当然也存在部分BUG会导致PMON清理过程非常慢。

举例来说，bug 9312879描述了一种场景：PMON 需要获得某个Mutex以便清理某个dead process，但是该Mutex又被其他进程持有，则PMON甚至无法开始真正清理并释放Mutex。


其中cursor: pin S wait on X，是某个进程为了共享操作例如执行pin游标而以SHRD S mode申请mutex， 但是未立即获得，但是该游标被其他进程以EXCL X mode 持有了。常见的原因有2种，一是过多子游标的SQL（即AWR中的SQL ordered by High Version Count），特别是有关部分X$、V$视图的查询；二是过高的硬解析。
AWR中相关信息如下：
[img]http://www.orasql.com/blog//uploadfiles/5462064d-c053-45b9-9d0b-eee422c0322c_88057.png[/img]
这2个SQL Version Count超过了100，有点偏高，且一个是EM发起的，另一个是通过sqlplus手工执行。建议业务时间，先测试确认对系统性能没有影响，然后再到生产环境执行。
另外，从实例负载信息来看，941次解析中有5.4个硬解析，这个值虽然不高，但是还有优化空间，加强绑定变量的使用。
参考下面2篇blog:
http://www.askmaclean.com/archives/cursor-pin-s-wait-on-x.html
http://www.dbaleet.org/shoug_share_session_how_to_troubleshoot_and_fix_high_version_count_issue/