ash中通过session_id、blocking_session、p1（游标地址）和sql_id四者交叉定位cursor: pin s wait on x事件，p1需转为raw后关联v$sql或x$kglob查真实sql，因v$session无法捕获瞬态阻塞而ash每秒采样可回溯历史。
ASH里怎么看cursor: pin S wait on X的会话堆栈
这个等待事件本质是会话在获取共享池中游标对象的S锁时，被另一个持有X锁的会话阻塞。ASH（v$active_session_history）是唯一能回溯到“谁在等、谁在占、等了多久、在哪条SQL卡住”的实时证据源。
关键不是查event字段，而是结合session_id、blocking_session、p1text/p1（即object address）和sql_id四者交叉定位：
SELECT sample_time, session_id, blocking_session, event, p1text, p1, sql_id, program FROM v$active_session_history WHERE event = 'cursor: pin S wait on X' AND sample_time > SYSDATE - 1/24 ORDER BY sample_time DESC;- 如果
blocking_session非空，直接查该会话当时的sql_id和program；若为空，说明阻塞源已退出，需靠p1（游标地址）反查历史缓存 -
p1text必须是object address，否则不是真因——有些监控脚本误把cursor: pin S和cursor: pin S wait on X混为一谈
用p1值反查被争用的游标对象
p1是游标在共享池中的内存地址（十六进制），不能直接当对象名用。得靠x$kglob或v$sql关联定位真实SQL：
- 先转成10进制：
SELECT TO_NUMBER('00000009A8B7C65D', 'xxxxxxxxxxxxxx') FROM dual;（把ASH里查出的p1值代入） - 再查
x$kglob：SELECT kglnaobj, kglhdadr, kglobt03 FROM x$kglob WHERE kglhdadr = HEXTORAW('00000009A8B7C65D');（注意：kglhdadr是RAW类型，需用HEXTORAW匹配） - 更稳妥的方式是查
v$sql：SELECT sql_id, sql_text FROM v$sql WHERE address = HEXTORAW('00000009A8B7C65D');（但仅限该游标仍在shared pool中） - 如果
v$sql查不到，说明已被老化淘汰，只能靠x$kglob.kglnaobj看SQL摘要，或结合AWR报告里的Top SQL交叉验证
为什么v$session不总能抓到阻塞链
v$session只反映当前快照，而cursor: pin S wait on X常发生在毫秒级争用中，阻塞源可能在你执行查询前就已释放X锁。ASH每秒采样一次，保留最近1小时（默认），是唯一能捕获瞬态阻塞的视图。
- 单独查
v$session看到blocking_session为0，不代表没发生过阻塞——只是此刻没卡住 -
v$session_wait里的wait_time为0且state=WAITING时，才表示正在等；但ASH里time_waited字段永远是0（因为是采样点，非累计值） - 不要依赖
dbms_monitor开启SQL跟踪来抓这个事件——开销太大，且无法回溯历史，不如直接查ASH+AWR
常见误判：把硬解析高峰当成cursor pin争用
大量cursor: pin S wait on X往往伴随library cache lock或library cache pin，但根源未必是SQL写法问题，更可能是共享池配置或应用行为异常。
- 检查
shared_pool_size是否过小：频繁老化导致同一SQL反复硬解析，每个硬解析都要申请X锁，引发串行化瓶颈 - 确认是否存在未绑定变量的SQL（
WHERE id = 123vsWHERE id = :b1），这类SQL在共享池里生成大量重复子游标，加剧pin竞争 - 观察
v$sgastat中free memory是否长期低于50MB，以及library cache的gethitratio是否低于95%——这两项比ASH事件本身更能说明底层压力来源
真正难处理的不是查到哪条SQL在等，而是判断那个被p1指向的游标，到底是因为硬解析太频繁、还是因为某个长事务一直没释放X锁、又或者共享池碎片严重。这些需要ASH、AWR、x$表三者联动，单看一个视图容易归错因。
