而从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’：

　　其实这里已经指出“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，0×5cf即10进制的1487。

　　而在稍后面部分，可以看到：

　　这里有Mutex请求的更详细的信息，Mutex 0×3ff3c3d28(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′：

　　可以看到，这个会话正在等待’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。

　　继续往后查看：

　　上面一段信息表明，正是1487这个会话以EXCLUSIVE方式持有idn=de12d336的这个mutex，这正是1471会话正需要以SHARE方式获取的Mutex。

　　上面一段信息表明，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‘，找到如下内容：

　　可以看到的确有会话(1497)正在以共享方式持有idn=7fff00005336的mutex。往前查看，可以看到会话信息：

　　再往前可以找到进程信息：

　　可以看到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引起的相关问题。