这是一个朋友单位的库，据说该库hung了一段时间，从alert log来看，中间有2小时是没有任何信息，难道hung了2个小时吗 ？ alert log 如下：

上述的信息是很简单的，提到了system state dump，下面我们来看下朋友提供的dump. 首先利用脚本先格式化一下：

很显然，从脚本格式化之后的信息来看，这部分信息是我们要分析的关键：

19和32都是holder，而32 正在等待19. 注意，这里的19,32其实都是值的orapid。
我们可以看到，orapid 32正在正待Latch 70000006b9d8008，而orapid 32在等待19，那么orapid 19可能就是我们需要分析的关键了。 从这里来看，orapid 19似乎同时持有了一个mutex和latch，下面我们来分别看下orapid 19和32 的详细信息：

我们可以看到orapid 32是一个用户进程，正在等待library cache latch，latch地址是：70000006b9d8008
从possible holder pid = 19 ospid=10027060 可以看出，这个latch正在被orapid 19所持有，下面我们搜索关键字:process 19

我们可以看到orapid 19这个进程正在持有llibrary cache latch 70000006b9d8008没有释放，到前面的orapid 32一直等待。
然而我们可以看到,orapid 19虽然持有了70000006b9d8008这个latch,然而同时它也在等待一个library cache latch 70000006b9d7f68
我们可以看到这个orapid 19的进程其实是J001，其状态已经为dead了。同时我们分析下面的mutex信息，发现该进程同时还持有了mutex： Mutex 70000003eec4be0(534, 0) idn ad39e34 oper EXCL
从这句话我们可以看出，orapid 19还持有了mutex ad39e34，而且mode为exel，即排他模式. 根据这个mutex 地址，我们进行搜索，发现 Oracle Pmon进程正在申请这个Mutex，如下：

可以看到pmon进程一直在等待这个mutex，也需要申请获得排他模式的mutex（类似传统的排他模式的library cache pin).
而由于这个mutex被前面的orapid 19（j001）锁持有，没有释放，导致pmon进程挂起。
最后我们简单的总结下：
1、大量的进程在等待library cache latch，而该latch被orapid 19（J001）进程所持有.

2、J001进程持有library cache latch不释放，同时还申请持有mutex，该进程状态是dead

3、Pmon进程申请排它模式的Mutex,而该mutex被J001进程持有，且状态也是排它模式.

4、按理说J001进程死掉之后，其持有的latch信息应该都会被pmon进程所清理释放掉，因为   这本身就是pmon进程的分内之事，然而由于mutex的原因，导致pmon进程挂起。

5、最后由于pmon进程也无法获得mutex，导致无法清理j0001进程，最后导致j0001阻塞了大量会话，   出现大面积library cache latch等待，最后整个系统hung.
6、个人认为问题的根据还是mutex的问题，library cache latch只是表象.