I think it is very difficult if not impossible to understand “cursor: pin S wait on X” without the knowledge of “cursor: pin S“. So this blog will start with “cursor: pin S” along with basics of mutex.
Also see my blog about “cursor:pin s” with more detailed info https://swervedba.wordpress.com/2011/03/30/cursor-pin-s/
Oracle introduced Mutexes in Oracle Version 10.2 and they stand for mutual exclusion (functionality is similar to mutexes in c). Mutexes are used to protect data or other resources from concurrent access.
Working of Oracle Mutexes
Oracle uses counters in implementing mutexes. The counters are called as reference counters
1. Every time a particular mutex is obtained, Oracle will increment its value.
2. Every time a particular mutex is released, Oracle will decrement its value.
Cursor Pin S : A wait even that occurs when a session wants a specific mutex in shared mode on a specific cursor. As mentioned in the previous section, Oracle has to update the ref counters to get the mutex
However it is very important to understand that access to these counters are not concurrent. If there are concurrent sessions trying to obtain a mutex, then only one session can actually increment or decrement the reference counter at a time. Therefore concurrent sessions requesting the mutex must wait. This wait is called as “cursor: pin s” wait.
In short
“cursor: pin s” wait event occurs when Oracle wants a specific mutex in shared mode on a specific cursor but could not obtain it as it was not able to update the reference counters (Not because another session was holding the mutex in exclusive mode) .
“cursor: pin S wait on X” wait event occurs when Oracle is not able to get the mutex in share(S) mode because some other session is holding the same mutex in exclusive(X) mode.
Recent Comments