Pin S wait on X is usually due to high parses. So check for high parsing sqls or tune application to share cursors. For further diagnosis, please review following note ：Note:1349387.1 Trouble shooting 'Cursor: Pin S wait on X' wait 通常是由于高分析。 所以檢查高解析sqls或調整應用程序共享游標。 如需進一步診斷，請查看以下注意事項Note:1349387.1 Trouble shooting 'Cursor: Pin S wait on X' wait
What causes 'Cursor: pin S wait on X' waits?
* Firstly, ensure that the shared pool is sized correctly. If the shared pool is under sized or under load generally, this may manifest itself as 'Cursor: pin S wait on X'. If Automatic Memory Management is being used then this should not normally be an issue. See: Document 443746.1 Automatic Memory Management (AMM) on 11g *Frequent Hard Parses If the frequency of Hard Parsing is extremely high, then contention can occur on this pin.
*High Version Counts When Version counts become excessive, a long chain of versions needs to be examined and this can lead to contention on this event
* Known bugs
*Parse Errors, as following note indicates: Document 1353015.1 How to Identify Hard Parse Failures
solution: select p2raw from v$session where event = 'cursor: pin S wait on X';
select p2raw, to_number(substr(to_char(rawtohex(p2raw)), 1, 8), 'XXXXXXXX') sid from v$session where event = 'cursor: pin S wait on X'; select sid,
serial#,
SQL_ID,
STATUS,
STATE,
BLOCKING_SESSION,
BLOCKING_SESSION_STATUS,
EVENT
from v$session
where SID = &sid;
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. 由于錯誤7568642 BLOCKING_SESSION為空當等待事件為"CURSOR：PIN S WAIT ON X"，blocking_session未在10.2中填充。錯誤在11g R1中修復
In 11g and 12g, the blocking session can be found directly using the following sql: 在11g和12g中，可以使用下面的sql直接找到阻塞會話
select sid, serial#, SQL_ID, BLOCKING_SESSION, BLOCKING_SESSION_STATUS, EVENT from v$session where event = 'cursor: pin S wait on X';
