【翻译自mos文章】找到'cursor: pin S wait on X' 等待事件的阻塞者session(即：持有者session)

本文提供了一种方法来确定导致'cursor:pinSwaitonX'等待事件的阻塞者会话。通过使用v$session或v$session_wait表中的p2raw列，可以获取持有该锁的会话ID，并进一步了解该会话正在执行的操作。在某些情况下，由于Bug7568642的影响，在Oracle数据库10.2版本中可能无法获取阻塞会话的信息，但在11g R1中已修复。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

找到'cursor: pin S wait on X' 等待事件的阻塞者session(即：持有者session)

来源于：
How to Determine the Blocking Session for Event: 'cursor: pin S wait on X' (Doc ID 786507.1)

适用于：
Oracle Database - Enterprise Edition - Version 10.2.0.1 to 11.2.0.3 [Release 10.2 to 11.2]
Oracle Database - Personal Edition - Version 10.2.0.1 to 11.2.0.3 [Release 10.2 to 11.2]
Oracle Database - Standard Edition - Version 10.2.0.1 to 11.2.0.3 [Release 10.2 to 11.2]
Information in this document applies to any platform.

目标：
本文对找到'cursor: pin S wait on X' 等待事件的阻塞者session 有帮助
关于该等待事件，请看：
Document 1377998.1 Troubleshooting: Waits for Mutex Type Events
Document 1349387.1 Troubleshooting 'cursor: pin S wait on X' waits
Document 1356828.1 FAQ: 'cursor: mutex ..' / 'cursor: pin ..' / 'library cache: mutex ..' Type Wait Events
Document 1377446.1 Troubleshooting Performance Issues

解决方案：
Cursor: pin S wait on X
当一个session为一个与pin相关的共享操作（such as executing a cursor）请求一个mutex时,该session会有Cursor: pin S wait on X等待事件。
但是该mutex不能被授权，因为该mutex正在被其他session以排他模式持有（比如 parsing the cursor）

v$session or v$session_wait中的p2raw列给出了 cursor: pin S wait on X等待事件的阻塞者session（持有者session）

SQL> select p2raw from v$session where event = 'cursor: pin S wait on X'; 

P2RAW 
---------------- 
0000001F00000000 
 <SID>  <RefCnt> 

The top bytes of p2raw is the blocker. 
Taking 0000001F (the first 8 bytes) and converting to decimal gives session id 31.

更简单的换算：

SQL> select p2raw,to_number(substr(to_char(rawtohex(p2raw)),1,8),'XXXXXXXX') sid 
     from v$session 
     where event = 'cursor: pin S wait on X'; 

P2RAW               SID 
----------------    --- 
0000001F00000000     31 

64 bit platforms
8 bytes are used.
Top 4 bytes hold the session id (if the mutex is held X)
Bottom 4 bytes hold the ref count (if the mutex is held S).

32 bit platforms 
4 bytes are used.
Top 2 bytes hold the session id (if the mutex is held X) 
Bottom 2 bytes hold the ref count (if the mutex is held S).


SQL> select p1, p2raw, count(*) from v$session 
     where event ='cursor: pin S wait on X'
     and wait_time = 0 
     group by p1, p2raw;

•p1 = the mutex Id
This has the same definition as v$mutex_sleep_history.mutex_identifier


•p2raw = holding Session Id | Ref Count
The most significant bytes always store the Holding Session Id (Holding SId). 
The least significant bytes always store the Ref Count.

 


The blocking session can be queried to see what it is doing and if anyone is blocking it. 

SQL> select sid,serial#,SQL_ID,BLOCKING_SESSION,BLOCKING_SESSION_STATUS,EVENT 
     from v$session where SID=31;

As a result of Bug 7568642 BLOCKING_SESSION EMPTY FOR "CURSOR: PIN S WAIT ON X"  the blocking_session is not populated in 10.2.The bug is fixed in 11g R1.
--这是一个bug

在11g中，阻塞者session可以用下面的sql 查询到：

SQL> select sid,serial#,SQL_ID,BLOCKING_SESSION,BLOCKING_SESSION_STATUS,EVENT 
     from v$session where event ='cursor: pin S wait on X'

 SID SERIAL# SQL_ID        BLOCKING_SESSION BLOCKING_SESSION_STATUS EVENT  
---- ------- ------------- ---------------- ----------------------- ----------  
 125    8190 3d3pd7g7dwuf6              135 VALID                   cursor: pin S wait on X

可能的原因：
One of the most likely causes of cursor: pin S wait on X is high parsing time. Therefore the reason for the high parse time should be investigated.