cursor: pin S
OTN 解释如下：
cursor: pin SA session waits on this event when it wants to update a shared mutex pin and another session is currently in the process of updating a shared mutex pin for the same cursor object. This wait event should rarely be seen because a shared mutex pin update is very fast.(Wait Time: Microseconds)
Parameter Description
P1 Hash value of cursor
P2 Mutex value (top 2 bytes contains SID holding mutex in exclusive mode, and bottom two bytes usually hold the value 0)
P3 Mutex where (an internal code locator) OR’d with Mutex Sleeps
今天收集性能报告Top 5
Top 5 Timed Foreground Events
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Avg
wait % DB
Event Waits Time(s) (ms) time Wait Class
------------------------------ ------------ ----------- ------ ------ ----------
DB CPU 205,412 99.8
db file sequential read 68,063 487 7 .2 User I/O
log file sync 139,316 233 2 .1 Commit
cursor: pin S 1,163,270 127 0 .1 Concurrenc
SQL*Net message from dblink 97,575 46 0 .0 Network
Oracle10gR2中引用的mutexes机制一定程度的替代了library cache pin，其结构更简单，相当于，每个child cursor下面都有一个mutexes这样的简单内存结构，当有session中要执行该SQL而需要pin cursor操作的时候，session需要以shared模式set这个内存位+1，表示session获得该mutex的shared mode lock.可以有很多session同时具有这个mutex的shared mode lock；但是在同一时间，只能有一个session在操作这个mutext +1或者-1。+1 -1的操作是排它性的原子操作。如果因为session并行太多，则导致某个session在等待其他session的mutext +1/-1操作,则该session要等待cursor: pin S等待事件。
当看到系统有很多session等待cursor: pin S事件的时候，要么是CPU不够快，要么是某个SQL的并行执行次数太多了而导致在child cursor上的mutex操作争用。如果是前者，则可以升级硬件。如果是因为SQL的并行太多，则要么想办法降低该SQL执行次数，要么将该SQL复制成N个其它的SQL。
select /*SQL 1*/ename from t where deptno=?
select /*SQL 2*/ename from t where deptno=?
select /*SQL …*/ename from t where deptno=?
select /*SQL N*/ename from t where deptno=?
这样就有了N个SQL Cursor,N个Mutex内存结构，就将争用分散开来，类似partition的作用了。
