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

同时,我们查看node 2节点的alert log也发现出现了node 1节点lms3进程超时的信息,如下:

我们可以看出是因为实例之间lms3进程通信交互出现超时导致crm1节点
被驱逐重启。根据crm1节点的alert log信息,我们可以整理一个如下的时间关系:
Aug 14 08:23:20   –lms3 Time out(lmon check发现)
Aug 14 08:25:54   –抛出ORA-29740: evicted by member 1, group incarnation 6错误,lmon 进程终止
Aug 14 08:25:54   –完成block recover(Doing block recovery for file 204 block 35113),由smon完成.
Aug 14 08:26:00   –crm1实例 abort关闭.
通过node 1节点的告警日志,我们可以发现,在Aug 14 08:23:20 时刻,lms3进程出现time out。通常来讲,lms进程出现超时,可能是由于系统压力过大,即load过高导致。 下面通过分析lgwr,lmd以及lmon 进程的trace来证实这一点。  首先我们来分析一下lgwr trace:

lgwr 进程trace仅仅截取了一小部分,从这部分内容来看,在凌晨03:25~03:59这个时间段,出现了log write 超时。通过对比可以发现,其实每天的03:25左右,lgwr write超时都是最严重的,说明这个时间点系统的IO压力是最大的.
然而03:59~ 08:25之间并没有出现别的信息,说明这个时间端内,系统的IO压力应该不大,但是这并不能说明系统的负载不高。下面我们继续分析lmon 进程的trace内容
Trace ngcrmdb1_lmon_6627610.trc内容如下:

从上面信息可以发现,orapid 1386这个session是地址10.200.141.139 登录的,主机名为:ngibweb3。
从上面信息来看,该进程的等待event是: SQL*Net message from client ,且该进程持有cbc latch长时间不释放。
对于进程持有cbc latch长时间不释放,主要有几种可能性:
1.  进程hang住;
2.  oracle bug或操作系统hang住.
Lms3 进程等待超过5分钟,且cbc resource被该进程持有,由此来看,该session 进程可能hang住了.
那么如何确认该进程可能已经hang住了 ?

可以看到该进程从8:08就在执行一个delete操作,直到8:25分,经历了17分钟. 我们从trace信息来看,该进程确实被挂起了1051秒。
那么,最后我们通过该进程的trace来确认一下,这个session在干什么?信息如下:

可以看到,该sql执行过差主要是因为进行了index full scan,需要注意的是,index full scan 进行的单块读。且由于
该环境是RAC,oracle需要在实例之间进行block的传输,确保数据的一致性以及cache fusion的作用,而该操作主要是
lms进程来完成的。然而该进程长时间持有cbc latch不释放,可能是由于该session 已经本身已经hang住。
最终由于node 1节点lms3 进程长时间获得不到cbc latch而出现超时,被lmon检查发现,以至于最后被lmon进程将实例重启。

    分享到:
18180207355
加Q咨询