一个朋友的库出现异常，6月30号就出现hang的问题，当时也给了建议直接kill会话解决了，没想到现在又出现了。简单的帮忙分析了一下原因，如下是alert log的信息：

从上面的alert log信息来看,可以看到GCR0进程启动失败，且核心进程LCK0也在等待latch:shared pool. 更重要的一点是：
连pmon进程也无法获得latch了。很明显，这个数据库hang住了。

对于Oracle hang问题,大家所了解做法是,先登录数据库，然后找到阻塞源头kill会话。

那么如果数据库hang住了之后，怎么登录呢？对于Oracle 10g以及之后的版本可以通过sqlplus -prelim / as sysdba方式登录.

然后进行hanganalyze dump,可惜是朋友这里操作了之后看到任何信息,那么只能进行systemstate dump和processstate dump了。

首先我们来看下PMON进程在等待为什么，为什么无法获得latch ？

可以看到pmon进程无法获得shared pool latch,而该资源(601091f8)正在被orapid=146所持有。下面来看下orapid 146在干什么？

ok,我们看到该进程正在持有 601091f8这个Child shared pool。朋友这里单独对orapid=146这个会话进行了dump，下面来深入分析一下：

可以看到该进程正在等待library cache: mutex X,而从最后的几行信息可以看到提示，fina blocker为：
inst: 1, sid: 2654, ser: 39173  （注意：11gR2之前这个信息是没有的，可见11gR2比较强大了）

既然这里提到最终的blocker 会话是2654，那么我们搜索关键字：sid: 2654 找到如下信息：

这里又提示该进程的最终blocker为 sid 1716。而2654 会话等待等待latch: shared pool。 下面继续搜索sid: 1716

可以看到sid 1716 在等待library cache: mutex X，而该会话的最终blocker为 sid：1899，继续搜索sid：1899

我们可以清楚的看到，最后又回到了sid:2654. 感觉饶了一圈又回来了。 如果你感觉这样分析有点费劲，那么可以通过
Oracle systemstate dump的格式化脚本将前面的systemstate dump的trace格式化，格式化之后，可以你会发现如下的信息：

我们把上面的信息简单整理一下，如下：

146(library cache: mutex X) 等待 138 (library cache: mutex X)
138(library cache: mutex X) 等待 142 (latch: shared pool)
142(latch: shared pool)     等待 105 (library cache: mutex X)
105(library cache: mutex X) 等待 138 (library cache: mutex X)

我们可以看出，很明显Oracle在这里形成了死锁，即library cache: mutex X 和 latch：shared pool构成了死锁.

当然这里如果是要解决问题，那么简单，将138,142,105 3个会话kill掉即可。

凭直觉我们可能就知道，这样的问题很可能是Oracle bug导致，注意朋友这里的环境已经是11.2.0.3.9了。

搜索了MOS，我认为90%的情况是这个Bug 17588480 – library cache mutex/shared pool latch deadlock (文档 ID 17588480.8)

可惜的是朋友这里没有做errorstack，无法准确定位到是不是这个bug，较为遗憾。