WAITEVENT: "cursor: pin S" Reference Note (文档 ID 1310764.1)

"cursor: pin S" Reference Note

This is a reference note for the wait event  "cursor: pin S" which includes the following subsections:

• Brief definition
• Individual wait details (eg: For waits seen in <View:V$SESSION_WAIT>)
• Systemwide wait details (eg: For waits seen in <View:V$SYSTEM_EVENT>)
• Reducing waits / wait times
• Known Bugs

See  Note:61998.1 for an introduction to Wait Events.

Definition:

• Versions:10.2 - 11.2 Documentation:10.2 11.1 11.2
• Mutexes were introduced in Oracle 10.2.
  A session waits for "cursor: pin S" when it wants a specific mutex in S (share) mode on a specific cursor and there is no concurrent X holder but it could not acquire that mutex immediately. This may seem a little strange as one might question why there should be any form of wait to get a mutex which has no session holding it in an incompatible mode. The reason for the wait is that in order to acquire the mutex in S mode (or release it) the session has to increment (or decrement) the mutex reference count and this requires an exclusive atomic update to the mutex structure itself. If there are concurrent sessions trying to make such an update to the mutex then only one session can actually increment (or decrement) the reference count at a time. A wait on "cursor: pin S" thus occurs if a session cannot make that atomic change immediately due to other concurrent requests. 
  Mutexes are local to the current instance in RAC environments.

Individual Waits:

  Parameters:

• Versions 10.2.0.1 - 11.2.0.2
  • P1 = idn
  • P2 = value
  • P3 = where (where|sleeps in 10.2)
  
  
  
  • idn Mutex identifier (gives hash_value of SQL)

    This is the mutex identifier value which matches to the HASH_VALUE of the SQL statement that we are waiting to get the mutex on. The SQL can usually be found using the IDN value in a query of the form:

     SELECT sql_id, sql_text, version_count 
       FROM V$SQLAREA where HASH_VALUE=&IDN;

    
    If the SQL_TEXT shown for the cursor is of the form " table_x_x_x_x" then this is a special internal cursor - see  Note:1298471.1 for information about mapping such cursors to objects. 
    
    P1RAW is the same value in hexadecimal and it can be used to search in tracefiles for SQL matching to that hash value.

    
    
    
  • value Mutex value (includes details of holder)

    This is the mutex value. The value is made up of 2 parts:

    • High order bits contain the session id of the session holding the mutex 
      (which should be 0 for a "cursor: pin S" wait as if there was an X holder the current session should be waiting on "cursor: pin S wait on X" instead)
    • Low order bits contain a reference count 
      (ie: the number of other S mode holders)

    
    
    
  • where Where in the code the mutex is requested from

    The high order bits of P3 give a number which represents a location in the Oracle code where the mutex was requested from. In 10.2 the low order bits of P3 gives a sleep value. In 11g the low order bits are all 0. 
    
    Warning: In 10.2 the low order sleep value can overflow into the high order bits, especially on 32bit platforms, giving a bad location value
    
    
    The high order bits of P3 can be mapped to a location name thus:

     SELECT decode(trunc(&&P3/4294967296),
    	    0,trunc(&&P3/65536),
    	      trunc(&&P3/4294967296)) LOCATION_ID
     FROM dual;
    
    Use the LOCATION_ID returned above in this SQL:
    
     SELECT MUTEX_TYPE, LOCATION 
       FROM x$mutex_sleep
      WHERE mutex_type like 'Cursor Pin%' 
        and location_id=&&LOCATION_ID; 

    
    The location names can be quite cryptic. In some cases the location may he helpful when diagnosing the cause of unexpected "cursor: pin S" waits.

  
  
  

  Wait Time:

Typically each wait is just a yield of the CPU in releases up to (and including) 11.2.0.2 
unless the fix for  bug 10411618 is installed and active.
A session will wait over and over on the same wait event until it acquires the mutex in S mode. If the wait is just a yield of the CPU then this can result in quite a high amount CPU, especially if there is very heavy concurrency for a particular cursor.

  Finding Blockers:

There is no actual blocker for this wait. Sessions wanting to acquire or release a specific mutex in S mode have to make an atomic update to the mutex structure and will register the wait if they are having trouble doing that due to many other concurrent sessions trying to acquire or release the same mutex.

Systemwide Waits:

The main scenarios that cause this event to show up system-wide are:

• Heavy concurrency for a specific mutex, especially on systems with multiple CPUs

  Use Active Session History (ASH) data, or sampled waits / 10046 trace to find the hot SQL statements. Typically these will be SQLs showing high Gets / Executions in AWR reports. The waits can actually appear worse for well tuned applications due to increased concurrency on specific SQLs.

  
  
  
• Waits for very many different "idn" values when under load

  If the system is CPU starved already then the "cursor: pins S" waits can occur across lots of cursors and the problem can become self aggravating as the waiting sessions can also push up CPU .

Information to help drill into systemwide waits can be obtained from:

• V$ACTIVE_SESSION_HISTORY / ASH reports
  Find common P1 (idn) values in the wait history for the "cursor: pin S" waits to home in on SQL which may be heavily competed. 
  
• V$MUTEX_SLEEP_HISTORY
  The MUTEX_IDENTIFIER column is the same as the P1 (idn) value exposed in V$SESSION_WAIT - it can be used to help identify hot SQL. 
  
• AWR and / or V$SQLAREA
  SQL with a very high executions executed by multiple concurrent sessions are typically the hot SQL causing the majority of waits.

Reducing Waits / Wait times:

Ensure that the version that you are using either has a some form of backoff or sleep option in place and enabled for "cursor: pin S" mutex waits. eg: By using the fix for  Bug:6904068 and setting the sleep time parameter to "1" for that fix (pre 11.2)
or for 11.2 releases ensure that the fix for  bug 10411618 is installed and active. 
This should help give breathing space between sessions competing for the same mutex thus avoiding CPU usage escalating and aggravating the waits. 

For any identified "hot" SQLs one can reduce the concurrency on specific cursors by replacing the one SQL with some variants which are executed by different sessions. 

eg: Consider "select name from acct where acctno=:1" is a very hot
    SQL statement then if clients can be put into groupings with: 
     some using "select /*A*/ name from acct where acctno=:1", 
     some using "select /*B*/ name from acct where acctno=:1", 
     some using "select /*C*/ name from acct where acctno=:1", 
    etc.. then the concurrency against any one of the SQLs can be reduced.

Known Bugs

You can restrict the list below to issues likely to affect one of the following versions by clicking the relevant button: 
                   

NB	Bug	Fixed	Description
P	16053781	11.1.0.6, 11.2.0.4	VMS: ORA-600 [kgxEndExamine-Bad-State] / 'cursor: pin S' waits in 10.2.0.5
	14029891	11.2.0.4, 12.1.0.1	mutex deadlock having SQL baselines on recursive dictionary cursor
	10411618	11.1.0.7.9, 11.2.0.1.BP12, 11.2.0.2.2, 11.2.0.2.BP06, 11.2.0.3, 12.1.0.1	Enhancement to add different "Mutex" wait schemes
	10270888	11.2.0.2.BP06, 11.2.0.3, 12.1.0.1	ORA-600[kgxEndExamine-Bad-State] / mutex waits after a self deadlock - superseded
	9591812	11.2.0.1.BP08, 11.2.0.2.2, 11.2.0.2.BP03, 11.2.0.3, 12.1.0.1	Wrong wait events in 11.2 ("cursor: mutex S" instead of "cursor: mutex X")
	9499302	10.2.0.5.5, 11.1.0.7.7, 11.2.0.1.BP08, 11.2.0.2, 12.1.0.1	Improve concurrent mutex request handling
	6904068		High CPU usage when there are "cursor: pin S" waits
	7441165	10.2.0.5, 11.2.0.2	Prevent preemption while holding a mutex (fix only works on Solaris)
	6795880	10.2.0.5, 11.1.0.7	Session spins / OERI after 'kksfbc child completion' wait - superceded

• '*' indicates that an alert exists for that issue.
• '+' indicates a particularly notable issue / bug.
• 'I' indicates an install issue / bug included for completeness.
• 'P' indicates a port specific bug.
• "OERI:xxxx" may be used as shorthand for ORA-600 [xxxx].

Note:

The above bug list shows only bugs tagged specifically as having caused "cursor: pin S" waits for customers.

Related:

  Note:1356828.1 Understanding 'cursor: mutex ..' / 'cursor: pin ..' / 'library cache: mutex ..' Type Wait Events

---

相关内容

产品

• Oracle Database Products > Oracle Database > Oracle Database > Oracle Database - Enterprise Edition

关键字

BUGTAG_ADDBUGS