Cursor: pin S wait on X

Posted 2020-08-15

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 on the same cursor 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 knowing issues.

What case ‘Cursor: pin S wait on X’ waits?

First, 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 on X’. If Automatic Memory Management is being used then then thish should not normally.

Frequent Hard Parsing.

If the frequency of hard parsing is extremely high, then contention can case cursor on this pin.

High version counts

When version counts become excessive, a long chain of version needs to be examined and this can be leading to contention on this event.

How to diagnose the cause.

Run AWR and ADDM reports during the time that you see ‘Cursor: pin S wait on X’  waits and also collect baseline reports when you do not see the waits to make comparisons. The baseline shows us the typical ‘background’ concurrency and activity going on during the time of both the issue and the baseline and may help identify culprit SQLs with high version counts.

To gather this it is suggested to run AWR and ADDM for half an hour to an hour interval as following:

@?/rdbms/admin/awrrpt

@?/rdbms/admin/addmrpt

Sometimes system state dump is necessary to match known issues. For example, if there is not candidate SQL in AWR,  captureng holder or waiter processes in system state allows you to focus in on potential problems. Run system state when processes apper hung on ‘Cursor: pin S wait on X’ waits:

Non-RAC

sqlplus "/ as sysdba" 

oradebug setmypid
oradebug unlimit
oradebug dump systemstate 266 wait 90 seconds
oradebug dump systemstate 266 wait 90 seconds
oradebug dump systemstate 266 quit 

RAC

$ sqlplus ‘/ as sysdba‘
oradebug setmypid
oradebug unlimit
oradebug setinst all
oradebug -g all hanganalyze 4 oradebug -g all dump systemstate 267 quit 

Errorstacks: Another way to obtain process information is with errorstack. Assuming you can identify a blocker, taking errorstacks will provide much the same information as systemstates but with a much reduced disk footprint for trace. Once the ospid of the blocker has been found, an errorstack can be generated: 

$ sqlplus
SQL> oradebug setospid <p.spid from above> oradebug dump errorstack 3
<< wait 1min>>
oradebug dump errorstack 3
<< wait 1min>>
oradebug dump errorstack 3
exit 

In particular, the stack from the resultant trace can be used to match known issues.
The system state and errorstacks are not easily readable; so a Service Request may need to be opened to read the files. 4. It is not always feasible to run system state dump. Thus, this note on finding the blocker can be used as well: 

Furthermore, the following sqls can be ran to identify the waiters: 

SELECT s.sid, t.sql_text
FROM v$session s, v$sql t
WHERE s.event LIKE ‘%cursor: pin S wait on X%‘ AND t.sql_id = s.sql_id 

本文出自 “DBA的天空” 博客，请务必保留此出处http://kevinora.blog.51cto.com/9406404/1863652