一. Mutex 与 latch的区别

从10.2版本开始mutex主要应用于library cache中，在10.2之前bucket上存在latch保护，同样的挂在bucket上的handle通过library cache latch保护，一个子latch保护多个bucket，这样就会造成latch本身的争用，比如大量的并发session访问相同的子latch。mutex则不然，每一个对象存在一个mutex，比如每一个bucket存在对应的mutex保护，每个handle存在一个对应的mutex保护，这样就极大的减少了争用，且mutex比latch代码量更小，操作更快，且无需死锁检查。mutex只是替代了latch，handle上的library cache lock和pin还是存在。

二.Mutex常见的等待事件

 在现有的版本中muext主要有以下几个等待事件:cursor:pin S, cursor:pin X,cursor:mutex S;cursor:mutex X

cursor:pin S wait X,library cahce:mutex X, library cache:mutex S.

1.cursor: pin S

当看到系统有很多session等待cursor: pin S事件的时候，要么是CPU不够快，要么是某个SQL的并行执行次数太多了而导致在child cursor上的mutex操作争用。

如果是SQL执行频率太高。最简单的做法是，将一条SQL拆分成多条SQL。增加SQL的版本数来降低并发。如一个SQL：

select * from dual;

可以改为如下4个SQL，则并发的争用可以下降4倍。

select /*1*/* from dual;

select /*2*/* from dual;

select /*3*/* from dual;

select /*4*/* from dual;

2.cursor: pin S wait on X

该等待事件主要是由hard parse造成的。pin S wait on X代表执行正在等待解析操作。

3.cursor:pin X

cursor:pin X等待事件发生的原因为其他会话对这个cursor对象已经持有了exclusive mutex pin或者是shared mutex pin.

一般通过systemstat进行定位

4.cursor:mutex S

Cursor: Mutex S 等待事件是指，一个会话以共享模式请求一个Mutex，而其他会话以排他模式正在持有Cursor 上的 Mutex。很少见的等待事件，考虑BUG导致。

5. cursor:mutex X

同上，考虑是否由 high version导致，需要确认cursor不能共享的原因(v$sql_shared_cursor)

6. library cahce:mutex X

常见原因:

-os资源不足(cpu、内存)

-sga设置不合理，shared_pool不足，或动态调整导致hard parse

-hot object contention

-hard parse

-sql high version count 由于子游标太多，扫描时会形成锁

-library cache object失效导致重编译

-bug