我之前曾经写过一篇Library cache内部机制详解，但是遗留了一些关于11g中mutex的改进的问题，最近因为有些11g的数据库频频发生mutex相关的等待事件，所以我又多这个问题做了一些探讨。

    关于Mutex，可以参考ORACLE mutex实现机制这篇文章，mutex是从10g开始引入的，在library cache中有大量的使用，它的主要作用有两个：一是用来替换library cache pin，二是作为更轻量级的latch使用。

    在9i中，Library cache lock有null,share,exclusive三种模式，lock的作用是控制进程间的并发访问。Library cache pin有share和exclusive两种模式，pin的作用是保证数据一致性，防止数据在访问时被交换出去。我们先来回顾一下library cache lock和library cache pin在不同场景下的使用方式：

    Procedure/function/trigger

    访问对象：需要在object handle上获取一个share类型的library cache lock，然后在data heap上获取share类型的library cache pin，同时在依赖的对象的上获取share类型的library cache lock和pin，保证依赖的对象不能被修改。

    编译对象：需要在object handle上获取一个exclusive类型的library cache lock，然后在data heap上获取exclusive类型的library cache pin，同时在依赖的对象上获取share类型的library cache lock和pin，保证依赖的对象不能被修改。

    当持有对象的library cache pin时，同时会在row cache中对相应的对象加锁，就是row cache lock，阻止可能导致数据字典信息混乱的DDL发生，row cache lock和library cache lock/pin一样，都是为了保证对象的一致性。

    Cursor

    Cursor execute：Cursor与procedure等实体对象不同的是，Cursor在执行时，在object handle上获取null类型的library cache lock，然后再data heap上获取share类型的library cache pin，同时在依赖的对象的上获取null类型的library cache lock和share类型的library cache pin。

    Cursor hard parse：Cursor硬解析需要在object handle上获取exclusvie类型的library cache lock，然后再data heap上exclusive获取类型的library cache pin，同时在依赖的对象上获取share类型的library cache lock和pin，保证依赖的对象不能被修改。

    Null类型的library cache lock与share类型的最大区别在于，Null lock并不起到并发控制的作用，它仅仅类似于一个触发器，当cursor所依赖的对象被修改时，需要获取exclusive类型的library cache lock/pin，这时Null lock被打破，Null lock会通知所有访问该对象的进程，表明cursor已经处于失效状态，需要重新解析，所以这种锁又称为“breakable parse lock”。

    从上述描述中我们可以看到，关于Cursor和procedure等对象，他们在执行时获取的library cache lock和pin的类型是不同的。

    Oracle 11g的变化

    Oracle从10g开始在library cache中引入mutex，在11g中mutex得到了更大规模的使用，主要有以下几个等待事件：

    cursor: pin X

     cursor: pin S

     cursor: pin S wait on X

     cursor: mutex X

     cursor: mutex S

     library cache: mutex X

     library cache: mutex S

    cursor: pin S，cursor: pin X，cursor: pin S wait on X这三个等待事件，实际上就是替代了cursor的library cache pin，pin S代表执行(share pin)，pin X代表解析(exclusive pin)，pin X wait on X代表执行正在等待解析操作。这里需要强调一下，它们只是替换了访问cursor的library cache pin，而对于访问procedure这种实体对象，依然是传统的library cache pin。

    cursor: mutex S，cursor: mutex X这两个等待也与cursor有关，一些资料上的解释是：cursor: mutex S用于Examining parent cursor, Querying V$SQLSTATS bucket，cursor: mutex X用于Loading new child cursor under parent, Modifying V$SQLSTATS bucket,Updating bind capture data。关于这两个等待的使用场景，目前还不是特别明确，我猜测它们是cursor: pin S，cursor: pin X这两个等待需要获取mutex时的产生的等待，因为cursor pin也是通过mutex实现的。

    从上面的分析我们看出，在11g版本中，library cache lock和library cache pin依然存在，Procedure和function等对象仍旧使用原有的方式，Null类型的library cache lock也依然存在，作用同样是在依赖对象改变时，通知失效的cursor，唯一的变化是cursor的library cache pin被mutex的相关等待所取代。

    library cache: mutex X，library cache: mutex S，这两个事件很明显是用来替代之前的library cache latch，主要作用是在hash bucket中定位handle时使用。而share pool latch和library cache load lock latch，latch依然存在，估计后续版本可能会逐步被替换掉。

    -EOF-

建议继续学习：

1. Buffer和cache的区别是什么？    (阅读：6839)
2. 谈冷热数据    (阅读：5765)
3. Linux操作系统中内存buffer和cache的区别    (阅读：5318)
4. 学习：一个并发的Cache    (阅读：4990)
5. 关于Linux的文件系统cache    (阅读：4798)
6. Twitter架构图(cache篇)    (阅读：4743)
7. 详解MyISAM Key Cache(前篇)    (阅读：4075)
8. 7个示例科普CPU Cache    (阅读：4143)
9. [squid] 过期时间在 60 秒内 squid 不 Cache 的问题    (阅读：3982)
10. 为什么程序员需要关心顺序一致性（Sequential Consistency）而不是Cache一致性（Cache Coherence？）    (阅读：3530)