11g等待事件之library cache: mutex X

转载：

11g等待事件之library cache: mutex X

    (2014-04-08 16:19:09)

转载▼

分类： Oracle

library cache: mutex X替代了之前的library cache latch，主要作用是在hash bucket中定位handle时使用。（比如SQL硬解析时，需要往hash bucket中新增一个cursor时，需要library cache latch）。如下图所示:

在10g及其以后版本中,很多latch使用mutex代替,我们常见的Library cache: mutex X is similar to library cache wait in earlier version.(_kks_use_mutex_pin=false可以禁止mutex)
文档上面的解释如下：
The library cache mutex is acquired for similar purposes that the library cache latches were acquired in prior versions of Oracle. In 10g, mutexes were introduced for certain operations in the library cache. Starting with 11g, the library cache latches were replaced by mutexes, hence this new wait event.
Mutexes are a lighter-weight and more granular concurrency mechanism than latches. Mutexes take advantage of CPU architectures that offer the compare and swap instructions (or similar). The reason for obtaining a mutex in the first place, is to ensure that certain operations are properly managed for concurrency. E.g., if one session is changing a data structure in memory, then another session must wait to acquire the mutex before it can make a similar change – this prevents unintended changes that would lead to corruptions or crashes if not serialized.
This wait event is present whenever a library cache mutex is held in exclusive mode by a session and other sessions need to wait for it to be released. There are many different operations in the library cache that will require a mutex, so its important to recognize which “location” (in Oracle’s code) is involved in the wait. “Location” is useful to Oracle Support engineers for diagnosing the cause for this wait event.
Individual Waits:

产生library cache latch原因
每一个sql被执行之前，先要到library cache中根据hash_value查找parent cursor,这就需要先获得library cache latch；找到parent cursor后，就会去查找对应的child cursor,当发现无法找到时，就会释放library cache latch，获得share pool latch分配空间给硬解析后的产生的执行计划；然后再次获得library cache latch进行把执行计划放入share pool,转入library cache pin+lock(null模式)开始执行sql.library cache latch 的个数有限(与CPU_COUNT参数相关)，当数据库中出现大量硬解析的时候，某一个sql无法得到library cache latch就会开始spin,达到spin count后还没得到，就会开始sleep,达到sleep时间后,醒来还再次试图过的library cache latch得不到就在spin再得不到又sleep…依此类推.
综上可知: 在sql执行的过程中可以看出在出现High Versions Count和Hard Parse的情况下都有可能出现library cache latch等待.

查了下metalink，与"library cache: mutex X"等待相关的BUG大约有30多个，会在11G各个版本之间发生，所以碰到这个等待事件，可以先确认下是不是碰上BUG了。以下两个BUG，在网上好象 大家经常碰到，给出metalink相关的描述：

Bug 5928271 - Excessive waits on "library cache: mutex X" [ID 5928271.8]

Versions >= 11.1.0.6 but BELOW 11.2
This fix alleviates some waits on "library cache: mutex X" when looking
up a library cache object.

Bug 9530750 High waits for 'library cache: mutex X' for cursor Build lock
Versions BELOW 12.1
High waits may be seen for "library cache: mutex X" for
a build lock mutex with a call stack including kksGetBuildLock.

Rediscovery Notes:
The mutex is for an object with a name like "$BUILD$.xxxxxxxx"

参考：
metalink相关文章
《Oracle Wait Interface A Practical Guide to Performance Diagnostics & Tuning》
《Oracle Core_ Essential Internals for DBAs and Developers - Jonathan Lewis》http://blog.tanelpoder.com/2008/08/03/library-cache-latches-gone- in-oracle-11g/