Phone:18180207355 提供专业Oracle&MySQL数据恢复、性能优化、迁移升级、紧急救援等服务

一个朋友的库出现异常,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,较为遗憾。

    分享到:
18180207355
加Q咨询