A session posts this event when requesting to pin a cursor in exclusive mode, cannot accomplish the pin by spinning, and therefore sleeps. It takes only a single session with a shared mutex pin to prevent an exclusive acquisition. A cursor must be exclusively pinned while it is being created. You wouldn't want another session to create or change the same cursor at the same moment.

A session posts this event when requesting a pin in shared mode, but must wait because another session has the mutex in exclusive mode. For example, if a session simply wants to execute the cursor, it must acquire the mutex in shared mode. However, if another session is building or altering the cursor (which requires an exclusive pin) while the session is waiting to execute it, it will post this event. Performance analysts have seen this event when cursors are being rebuilt (perhaps an underlying table has been altered) while a number of sessions want to execute the cursor.

If you review Table 7-1, you'll notice the key to solving mutex-related contention is understanding both the wait event and what is occurring within your application. For example, if the wait event is cursor: pin S (which is the most likely), it's possible that the same cursor is being repeatedly executed by a few users, a few cursors are being executed by many users, or even one simple SQL statement is being executed by hundreds of users concurrently. Once you understand this, you'll then look for the SQL statement with a relatively high execution rate and do anything you can to reduce its execution rate. Using the wait event to lead you to the particular cursor-related situation and understanding the nature of your application is your best solution path.