11g等待事件之library cache: mutex X
11g等待事件之library cache: mutex X
library cache: mutex X替代了之前的library cache latch，主要作用是在hash bucket中定位handle时使用。（比如SQL硬解析时，需要往hash bucket中新增一个cursor时，需要library cache latch）。如下图所示:
文档上面的解释如下：
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:
Parameters:
P1 = “idn” = Unique Mutex Identifier
P2 = “value”
P3 = “where” = location in code (internal identifier) where mutex is being waited for
@The meaning of the code for “where” can be found by looking in kgl0.h for entries with the prefix “”kglml_XXX”. For example, if P3=2, then it corresponds to “kglml_kglget2″. You can then search source code for this symbol to see where the mutex is acquired.
测试一个硬解析的场景如下：
conn scott/tiger create table testlib1 (id number) ; create table testlib2 (id number) ; create table testlib3 (id number) ; create table testlib4 (id number) ; create table testlib5 (id number) ; create table testlib6 (id number) ; create table testlib7 (id number) ; create table testlib8 (id number) ; create table testlib9 (id number) ; create table testlib10 (id number) ; create table testlib11 (id number) ; create table testlib12 (id number) ; create table testlib13 (id number) ; create table testlib14 (id number) ; create table testlib15 (id number) ; create table testlib16 (id number) ; create table testlib17 (id number) ; create table testlib18 (id number) ; create table testlib19 (id number) ; create table testlib20 (id number) ; vi test4.sh #!/bin/ksh i="$1" while true do echo $i sqlplus scott/tiger << EOF select * from testlib$i where id = $RANDOM; exit EOF done alter system flush shared_pool; exec DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT (); nohup sh test4.sh 1 & nohup sh test4.sh 2 & nohup sh test4.sh 3 & nohup sh test4.sh 4 & nohup sh test4.sh 5 & nohup sh test4.sh 6 & nohup sh test4.sh 7 & nohup sh test4.sh 8 & nohup sh test4.sh 9 & nohup sh test4.sh 10 & nohup sh test4.sh 11 & nohup sh test4.sh 12 & nohup sh test4.sh 13 & nohup sh test4.sh 14 & nohup sh test4.sh 15 & nohup sh test4.sh 16 & nohup sh test4.sh 17 & nohup sh test4.sh 18 & nohup sh test4.sh 19 & nohup sh test4.sh 20 & exec DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT ();
生成awr report，查看等待事件：
Top 5 Timed Foreground Events
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Avg
wait % DB
Event Waits Time(s) (ms) time Wait Class
------------------------------ ------------ ----------- ------ ------ ----------
DB CPU 104 111.9
library cache: mutex X 1,920 3 1 2.9 Concurrenc
latch: shared pool 237 1 5 1.2 Concurrenc
latch: row cache objects 146 1 5 .9 Concurrenc
cursor: pin S wait on X 42 1 13 .6 Concurrenc
^LHost CPU (CPUs: 16 Cores: 8 Sockets: 2)
~~~~~~~~ Load Average
Begin End %User %System %WIO %Idle
--------- --------- --------- --------- --------- ---------
1.12 6.89 25.0 18.5 2.7 56.1
我们的hard parse
Load Profile Per Second Per Transaction Per Exec Per Call
~~~~~~~~~~~~ --------------- --------------- ---------- ----------
DB Time(s): 2.8 4.0 0.00 0.00
DB CPU(s): 3.1 4.5 0.00 0.00
Redo size: 31,740.9 46,051.8
Logical reads: 3,625.8 5,260.6
Block changes: 83.5 121.1
Physical reads: 0.2 0.4
Physical writes: 0.2 0.2
User calls: 2,719.4 3,945.5
Parses: 1,856.1 2,693.0
Hard parses: 137.4 199.4
W/A MB processed: 0.8 1.2
Logons: 129.7 188.1
Executes: 1,830.6 2,656.0
Rollbacks: 0.2 0.3
Transactions: 0.7
查了下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/
