Library cache内部机制详解II
我之前曾经写过一篇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上获取一个null类型的library cache lock(首先获取share，然后转换为null)，然后在data heap上获取share类型的library cache pin，在其所依赖的表上不加任何lock和pin(先申请share类型的lock，申请到之后不再持有任何lock和pin，允许修改procedure所依赖的对象，即允许被打破)。
编译对象：需要在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：在object handle上获取null类型的library cache lock(首先获取share，然后转换为null)，然后再data heap上获取share类型的library cache pin，在其所依赖的表上不加任何lock和pin(先申请share类型的lock，申请到之后不再持有任何lock和pin，允许修改cursor所依赖的对象，即允许被打破)。
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需要获取的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–
|
Wait event |
Latch |
|
|
9i |
library cache pin library cache lock library cache load lock |
shared pool library cache library cache pin library cache pin allocation library cache load lock |
|
10g |
cursor: mutex X cursor: mutex S cursor: pin S wait on X library cache pin library cache lock library cache load lock cursor: pin X cursor: pin S library cache revalidation library cache shutdown |
library cache library cache lock library cache pin library cache pin allocation library cache lock allocation library cache load lock library cache hash chains |
|
11g |
cursor: mutex X cursor: mutex S cursor: pin S wait on X library cache pin library cache lock library cache load lock library cache: mutex X library cache: mutex S cursor: pin X cursor: pin S library cache revalidation library cache shutdown |
library cache load lock shared pool |
引自：http://www.hellodb.net/2011/03/librarycache-mutex.html
