Mutex是Oracle从10g开始使用的一种数据结构，与latch极其类似，也是用于SGA内存结构的并发访问控制。在10g中，Mutex主要用于保护Cursor相关的内存结构，Parent Cursor, Child Cursor , Cursor Stat，同时兼有Pin Cursor的并发访问控制作用。
而从11g开始，Mutex又代替了library cache latch等多个与library cache相关的latch。
Mutex与latch相比，有哪些优点？我个人认为最重要的有2点：
- Mutex通常在被保护对象内部，这样mutex的数量就多了很多，争用就更少。比如11g中，每一个Latch Latch Hash Bucket由一个mutex保护，而bucket数量高达131072，相比library cache latch最多只有67个child latch，数量上多了很多。很显然，分布在131072个Mutex上的竞争比67个Library cache latch上的竞争少得多。
- Mutex从结构上来讲比latch更多简单，整个Mutex只有十几个字节，而Oracle在对Latch的结构优化和精简的情况下最少也有100多个字节。这样更小的结构意味着在处理Mutex时也只需要更少的指令，而更快。
- Mutex代替Cursor上的library cache pin，比library cache pin更有效率。
本文主要描述如何通过system state dump来分析mutex的等待，因此对Mutex的工作机制以及相应的等待事件详解不做过多介绍。有机会我会在另外的文章中专门来讲这两部分。
我们来分析的system state dump来源于一个朋友，他的系统里面出现大量的'cursor: pin S wait on X'和'cursor: Mutex X'等待事件。他将产生的system state dump发给我，以分析出产生问题的root cause。由于system state dump比较在在，同时里面涉及的一些内容不适合放在网上，因此本文只给出分析过程，没有上传trace文件。数据库的版本是11.1.0.7。
首先试图找到'cursor: pin S wait on X'等待的阻塞进程，随便找到一个等待cursor:pin S wait on X的会话，在dump trace 文件中查找waiting for 'cursor: pin S wait on X'：
(session) sid: 1471 ser: 57513 trans: (nil), creator: 0x450d504f0 flags: (0x45) USR/- flags_idl: (0x1) BSY/-/-/-/-/- flags2: (0x40008) -/- DID: , short-term DID: txn branch: (nil) oct: 3, prv: 0, sql: 0x455d15680, psql: 0x45bd0c8c8, user: 92/XXXX ksuxds FALSE at location: 0 service name: SYS$USERS client details: O/S info: user: idol, term: unknown, ospid: 1234 machine: program: JDBC Thin Client application name: JDBC Thin Client, hash value=2546894660 Current Wait Stack: 0: waiting for 'cursor: pin S wait on X' idn=de12d336, value=5cf00000000, where|sleeps=572cf03e3 wait_id=56059196 seq_num=26772 snap_id=1 wait times: snap=0.001772 sec, exc=0.001772 sec, total=0.001772 sec wait times: max=0.010000 sec wait counts: calls=1 os=1 in_wait=1 iflags=0x5a2 There is at least one session blocking this session. Dumping one blocker: inst: 1, sid: 1487, ser: 5556
其实这里已经指出“inst: 1, sid: 1487, ser: 5556”，表示阻塞的会话是sid,serial#为1487,5556。那么如果这里没有这个信息，那么我们从哪里去寻找blocker？注意前面一段信息：idn=de12d336（对cursor来说其实是sql的hash value的低4字节）, value=5cf00000000, where|sleeps=572cf03e3，这里idn表示mutex的identifier，即mutex的标识，value的高8字节（64位系统是高8字节，而32位系统是高4位字节）是SID，0x5cf即10进制的1487。
而在稍后面部分，可以看到：
KGX Atomic Operation Log 0x455507d20 Mutex 0x3ff3c3d28(1487, 0) idn de12d336 oper GET_SHRD Cursor Pin uid 1471 efd 0 whr 5 slp 13085 opr=2 pso=0x454d03f00 flg=0 pcs=0x3ff3c3ca8 nxt=0x41720aca0 flg=35 cld=0 hd=0x455d0dda8 par=0x3ff3c4650 ct=0 hsh=0 unp=(nil) unn=0 hvl=ff3c4448 nhv=1 ses=0x45181f760 hep=0x3ff3c3d28 flg=80 ld=1 ob=0x3ff3c3868 ptr=0x412040780 fex=0x41203faf0
这里有Mutex请求的更详细的信息，Mutex 0x3ff3c3d28(1487, 0) idn de12d336 oper GET_SHRD表明这个请求是以SHARE方式请求，但是Mutex被1487这个会话持有。idn与前面idn相匹配。Cursor Pin uid 1471 efd 0 whr 5 slp 13085 这里表明Mutex的类型是Cursor Pin，正是前面提到的Mutex的一种。uid 1471表明是当前请求的SID为1471。
'cursor: pin S wait on X'等待类似于以往的library cache pin等待，表示需要将cursor pin在内存中。这个等待出现，表明有会话正在修改这个cursor，比如正在执行解析，生成执行计划等。
接下来我们看SID=1487的会话正在等待什么，或者说是在执行什么操作，查找'(session) sid: 1487'：
(session) sid: 1487 ser: 5556 trans: (nil), creator: 0x450d514f0 flags: (0x45) USR/- flags_idl: (0x1) BSY/-/-/-/-/- flags2: (0x40008) -/- DID: , short-term DID: txn branch: (nil) oct: 3, prv: 0, sql: 0x455d15680, psql: 0x45bd0c8c8, user: 92/XXXXX ksuxds FALSE at location: 0 service name: SYS$USERS client details: O/S info: user: idol, term: unknown, ospid: 1234 machine: program: JDBC Thin Client application name: JDBC Thin Client, hash value=2546894660 Current Wait Stack: 0: waiting for 'cursor: mutex X' idn=5336, value=1, where|sleeps=3385a5f33 wait_id=500096450 seq_num=64401 snap_id=1 wait times: snap=0.000000 sec, exc=0.000000 sec, total=0.000000 sec wait times: max=0.000000 sec wait counts: calls=0 os=0 in_wait=0 iflags=0x15e0
可以看到，这个会话正在等待'cursor: mutex X'。不幸的是，这一次没有直接表明holder是谁了。idn=5336, value=1, where|sleeps=3385a5f33，这里value=1，很简单，但是表明的意义却不简单，这表明什么？低8字节为1，表明这个Mutex是被共享持有，而高8字节为0，这是共享持有的Mutex的正常状况，Mutex可能被多个会话共享持有，因此只有引用计数，而不会有持有的SID。这里1就是引用计数，表示被1个会话持有。只有在会话获取Mutex的过程中，才会暂时性的将Mutex的SID设为正在获取的SID，而一旦完成获取，就将Mutex中的SID即value的高8字节部分清0。
继续往后查看：
KGX Atomic Operation Log 0x4543ce390 Mutex 0x3ff3c3d28(1487, 0) idn de12d336 oper EXCL Cursor Pin uid 1487 efd 0 whr 1 slp 0 opr=3 pso=0x454daaa50 flg=0 pcs=0x3ff3c3ca8 nxt=0x41720aca0 flg=35 cld=0 hd=0x455d0dda8 par=0x3ff3c4650 ct=0 hsh=0 unp=(nil) unn=0 hvl=ff3c4448 nhv=1 ses=0x45181f760 hep=0x3ff3c3d28 flg=80 ld=1 ob=0x3ff3c3868 ptr=0x412040780 fex=0x41203faf0
上面一段信息表明，正是1487这个会话以EXCLUSIVE方式持有idn=de12d336的这个mutex，这正是1471会话正需要以SHARE方式获取的Mutex。
KGX Atomic Operation Log 0x45a2b7908 Mutex 0x44b764498(0, 1) idn 7fff00005336 oper GET_EXCL Cursor Stat uid 1487 efd 8 whr 3 slp 28652 oper=OPERATION_DEFAULT pt1=(nil) pt2=(nil) pt3=(nil) pt4=(nil) u41=0 stt=0
上面一段信息表明，1487这个会话正在以EXCLUSIVE请求的mutex是idn=7fff00005336，Mutex类型是Cursor Stat。Cursor Stat类型的EXCLUSIVE方式请求通常是需要更新cursor的统计信息。而以SHARE方式请求通常是查询cursor的统计信息，比如说查询v$sqlstat视图。注意这里GET_EXCL表示正在以EXCLUSIVE方式请求获取（持有）mutex，而EXCL表示已经以EXCLUSIVE方式持有mutex。延伸开来，GET_SHRD表示请求SHARE方式的mutex，SHRD表示以SHARE方式持有mutex。REL_SHRD表示正在释放SHARE方式持有的mutex，也就是递减引用计数。
那么，接下来我们就要寻找是哪个会话持有了idn=7fff00005336的mutex。查找'idn 7fff00005336 oper‘，找到如下内容：
KGX Atomic Operation Log 0x45955b2f0 Mutex 0x44b764498(0, 1) idn 7fff00005336 oper SHRD Cursor Stat uid 1497 efd 7 whr 6 slp 0 oper=OPERATION_DEFAULT pt1=(nil) pt2=(nil) pt3=(nil) pt4=(nil) u41=0 stt=0
可以看到的确有会话（1497）正在以共享方式持有idn=7fff00005336的mutex。往前查看，可以看到会话信息：
(session) sid: 1497 ser: 29349 trans: (nil), creator: 0x45cccc3f0 flags: (0x51) USR/- flags_idl: (0x1) BSY/-/-/-/-/- flags2: (0x408) -/- DID: , short-term DID: txn branch: (nil) oct: 0, prv: 0, sql: (nil), psql: (nil), user: 0/SYS ksuxds FALSE at location: 0 service name: SYS$BACKGROUND Current Wait Stack: Not in wait; last wait ended 14005 min 23 sec ago Wait State: auto_close=0 flags=0x21 boundary=(nil)/-1 Session Wait History: 0: waited for 'db file sequential read' file#=2, block#=1952c, blocks=1 wait_id=1171 seq_num=1174 snap_id=1 wait times: snap=0.018420 sec, exc=0.018420 sec, total=0.018420 sec wait times: max=infinite wait counts: calls=0 os=0 occurred after 0.000034 sec of elapsed time
再往前可以找到进程信息：
PROCESS 38: ---------------------------------------- SO: 0x45cccc3f0, type: 2, owner: (nil), flag: INIT/-/-/0x00 if: 0x3 c: 0x3 proc=0x45cccc3f0, name=process, file=ksu.h LINE:10706, pg=0 (process) Oracle pid:38, ser:76, calls cur/top: 0x440d0ae48/0x43c5e5f88 flags : (0x2) SYSTEM flags2: (0x30), flags3: (0x0) int error: 0, call error: 0, sess error: 0, txn error 0 ksudlp FALSE at location: 0 (post info) last post received: 0 0 42 last post received-location: ksv2.h LINE:1603 ID:ksvpst: run last process to post me: 450d4b4f0 1 2 last post sent: 0 0 151 last post sent-location: kcrf.h LINE:3095 ID:kcrfw_redo_gen: wake LGWR after redo copy last process posted by me: 45ccbe3f0 1 6 (latch info) wait_event=0 bits=0 Process Group: DEFAULT, pseudo proc: 0x4510353e0 O/S info: user: oracle, term: UNKNOWN, ospid: 13549 OSD pid info: Unix process pid: 13549, image: oracle@xxxxx (m001)
可以看到m001这个进程持有了mutex。但是会话没有在执行任何sql语句，而从会话的等待来看，last wait ended 14005 min 23 sec ago ，这个是不正常的，m001进程应该是出现了异常。
m001进程是什么，这是mmon的slave进程，其中一个作用就是执行awr snapshot。很显然这个进程要访问v$sqlstat，是需要持有Cursor Stat类型的mutex的。
至此就找到了所有等待的root holder。不过把这个结果告诉维护这个库的朋友时，告知服务器之前“死”了，已经重启了。重启后检查数据库，发现在故障期间很长一段时间内的确是没有产生awr snapshot。至于m001进程出了什么异常，为什么会出现异常，本文就不再详细讨论。实际上服务器重启之后也没有继续跟踪这一问题。
mutex从设计上来说，与latch相比有着很明显的优点，只是作为新生事务（相对于目前仍然在广泛使用的10g来说）， 存在BUG的可能性比较大。深入了解mutex，可以帮助我们更好地诊断mutex引起的相关问题。