Tag Archives: shan nawaz
I will be presenting once again at this year InSync conference at Melbourne (Aug 21/22), Australia. My session is about Oracle GoldenGate Best Practices and performance optimization techniques. Last years conference was in Sydney convention center and had impressive list of speakers including Tom Kyte, Richard Foote, Andrew Holdsworth & Graham Wood. .. .. About InSync12 .. The InSync12 Conference and Exhibitor Showcase is a joint event of the Quest ANZ user group – representing JDE and PeopleSoft customers, and the Australian Oracle User Group (AUSOUG) representing the Technology, Development and Applications users. This is the fourth time the independent user groups in Australia will come together for one national conference. See link for more details http://www.insync12.com.au/
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.
“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.