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.

And again, it is very unlikely mutex waits will be the top wait event (when there is not a related mutex bug), but it occasionally does occur. So it's important to understand mutex serialization control (see Chapter 3) as well as library cache internals and diagnosis.