Troubleshooting 'library cache: mutex X' Waits.

What is a 'library cache: mutex X' wait?

The mutex feature is a mechanism to control access to in memory structures. It is used in a number of areas including the library cache.

The library cache is a memory area that holds parsed cursor structures needed to execute SQL.

Waits for 'library cache: mutex X' are similar to a library cache waits in earlier versions.  'library cache: mutex X' may be caused by many issues (including application issues, lack of sharing resulting in high version counts etc.) but essentially something is holding the mutex for "too long" such that other session have to wait for the resource.  If there is contention on the latches/mutexes that protect the library cache structures this means that there is stress on the parsing system. Parsing of SQL takes longer because it cannot get the resources they need. This delays other operations and generally slows the system.

Because of the varied causes, it is important to find the correct cause; so that the right solution can be implemented.

What causes 'library cache: mutex X' wait?

• Frequent Hard Parses - If the frequency of Hard Parsing is extremely high, then contention can occur on this pin.
• High Version Counts - When Version counts become excessive, a long chain of versions needs to be examined and this can lead to contention on this event
• Invalidations - An invalidation is a measure of the number of times a cached cursor is deleted from the cache because it is no longer valid. A cursor is invalidated because something has changed such that the copy of the cursor in memory is not valid any more. For example, regathering the statistics on an object or modifying a table definition is enough to invalidate a cursor for a query that is based on that object. When a cursor is invalidated, any sessions wanting to use the cursor need to wait for a valid version to be loaded. If there is excessive or unnecessary invalidation then significant waits for 'library cache: mutex X' can be seen.
• Reloads - Reload is a count of the number of times a cursor that previously existed in the cache, was searched for, found to not be there (because it had aged out etc) and then had to be re-compiled and re-loaded in to the library cache. High reloads are a bad thing because they indicate that you are doing work that you would not have had to do if your cache was setup appropriately so as not to remove the cursor in the first place. If a cursor is being reloaded then it cannot be grabbed for work by a session and this can lead to waits for 'library cache: mutex X'.
• Known Bugs