《Troubleshooting 'cursor: pin S wait on X' waits. (文档 ID 1349387.1)》
解释说明：
1.Oracle官方对该等待事件解释：
What is a 'Cursor: pin S wait on X' wait?
A cursor wait is associated with parsing in some form. A session may wait for this event when it is trying to get a mutex pin in Share mode but another session
is holding the mutex pin on the same cursor object in exclusive. Frequently, waits for 'Cursor: pin S wait on X' is a symptom and not the cause. There may be underlying tuning requirements or known issues.
2.当一个会话以X模式持有某个cursor（如sql/procedure/function/package body等）的mutex时，如果另一个会话需要以S模式请求该cursor的mutex；通常来讲，
对cursor进行硬解析时，会以X模式持有cursor的mutex，而对cursor进行软解析时，则会以S模式持有cursor的mutex；
3.举例说明：会话1正在硬解析目标sql，这时候会话2同时执行这条sql语句时（执行前需要对该语句进行软解析），会话2就会等待cursor:pin S wait on X 事件。
4.Cursor: pin S wait on X' wait等待事件的P1参数idn，实际上就是sql语句的hash_value，也就是说通过该等待事件的P1参数即可定位等待的实际对象
5.在定位了该等待事件所等待的对象后，该对象MUTEX的持有者即为该等待事件的源头。在trace文件中，可以通过oper EXCL关键字查找到持有者
6.通过以上systemstate trace截取内容可以看到cursor: pin S wait on X等待事件对应会话都在同一个idn上，也就是会话从属为同一个hash_value
-----------------------------------------------
会话969在等待cursor:pin S wait on X，其中有两个会话阻塞这个会话，一个是会话486，一个是会话1458，会话486等待cursor: pin S wait on X，同时
阻塞会话486的为1458,1458持有row cache lock等待事件，对应数据库对象为row_wait_obj#: 4294967295，同时会话259在等待cursor:pin S wait on X，阻塞
者也是1458，同时会话385在等待cursor:pin S wait on X，对应阻塞着是259
会话969对应阻塞者是会话486
会话486对应阻塞者是会话1458
会话23对应阻塞者是会话486
会话259对应阻塞者是1458
会话385对应阻塞者是259
source sessions blocking session final blocker idn
session 969 session 486 session 1458
session 23 session 486 session 1458
session 385 session 259 session 1458
分析到这里可以看到会话1458持有library cache: mutex X，对应idn为0xa0d627f0，和以上阻塞会话对应的hash value完全一致，可以评估被阻塞者持有
cursor:pin S wait on X等待事件，且相同的idn，被持有ibrary cache: mutex X等待事件的会话1458阻塞，接下来分析library cache lock的等待源头就能
找到这个trace文件的具体问题了，以下为会话1458的部分截图信息：
---------------------------------------------
以下为会话1458的部分截图信息：
解释说明：
library cache lock
1.当一个会话对library cache中的对象（主要是TABLE INDEX/CLUSTER/PROCEDURE等）进行修改（通常是指DDL操作）时，会以X模式持有该对象的library cache lock；
当一个会话在解析sql需要用到某个对象时，会以S模式请求该对象的library cache lock；
2.例如session 1正在对堆组织表进行DDL操作，另一会话session 2开始执行与该堆组织表相关的sql语句，那么此时session 2会等待library cache lock事件。
sid 2784 ser 56665, waiting for 'library cache lock'
sid 383 ser 64202, waiting for 'library cache lock'
sid 506 ser 23287, waiting for 'library cache lock'
其中会话2784对应库缓存句柄为handle address=0x22f76fcc0，总等待事件为=34 min 34 sec，阻塞会话为2182，该会话持有cursor: pin S wait on X等待事件，
阻塞2182同样还是会话1458，同时会话1220对应库缓存句柄为0x23f7be450，总等待时间为96 min 36 sec，阻塞该会话为506，同样的，会话506等待library cache lock，
总等待时间为13.631233 sec，阻塞506会话为2784
总结：
会话1458阻塞了352 sessions blocked，该对象持有row cache lock等待事件，对应row_wait_obj#: 4294967295，同时该会话在Session Wait History中持有
library cache: mutex X，也就是说会话1458以X模式持有cursor的mutex，同时会话23 286 969等以S模式持有cursor的mutex产生的等待。
---------------------------------------------
当一个会话以X模式持有某个cursor（如sql/procedure/function/package body等）的mutex时，如果另一个会话需要以S模式请求该cursor的mutex；通常来讲，
对cursor进行硬解析时，会以X模式持有cursor的mutex，而对cursor进行软解析时，则会以S模式持有cursor的mutex，同时会话506 2784以S模式请求该对象的library cache lock
，1458会话以X模式持有该对象的library cache lock未完成，造成以上阻塞，对应对象是row_wait_obj#: 4294967295
--------------------------------------------
《点亮梦想，拒绝平庸》
600团队（QQ群：851604218）
