love wife love life —Roger的Oracle/MySQL数据恢复博客

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

一个比较特殊的Oracle Rac案例

本站文章除注明转载外,均为本站原创: 转载自love wife love life —Roger的Oracle/MySQL数据恢复博客

本文链接地址: 一个比较特殊的Oracle Rac案例

前不久某客户一套Oracle RAC集群出现异常;当某个节点故障后,出现多个实例不断反复重启的情况(该rac环境上运行着7个Oracle 实例)。

最终会出现启动节点1 asm;数据会自动将节点2 实例全部驱逐挂掉。

我们首先来看最新的情况;其中一个核心实例crash:

 

从上面信息来看,数据实例和ASM实例失去了通信:数据库实例被asmb进程终止;进一步分析asm日志发现;在11:44:44秒时间点,该节点asm实例被强行终止,因此导致该节点上所有数据库实例均被强行终止。

我们继续来分析asm实例告警:

从节点2 asm日志来看,节点2asm实例被强行终止,是接收到节点1的终止信息;故进一步分析节点1 告警日志:

从节点1 日志来看,节点2的asm实例在11:44:44秒被强行终止;而节点1 asm实例启动时,mount磁盘组的时间点在11:44:52

因此初步怀疑是Oracle ASM实例在open期间做实例恢复时,出现异常,进而导致出现启动节点1 asm将节点2 asm实例强行终止的情况。

基于这个想法,检查两个节点asm 实例smon 进程trace文件发现如下信息:

进一步检查3月15号出故障的时间点的smon trace内容;发现ocrdiskgroup 存在异常:

从上面相信来看,asm实例在启动时,需要进行recovery操作;对于Oracle数据库而言,每一个磁盘组都被成为一个domain。

从节点1 smon的trace来看有detected lock domain的相关信息。由此可以判断,节点1 asm实例在启动时;当smon进程

进行恢复时,发现无法获得domain lock;进而不断尝试。最终将节点2 asm实例强行终止后,节点1 asm smon进程才能成功获得domain lock;

最终完成了节点1 asm实例的所有磁盘组mount成功。 此时节点2的asm实例已经强行终止。

实际上在节点1 asm alert log也有类似信息;如下:

该warning 现象意味着磁盘header信息出现了不一致的情况;因此进一步通过kfed 工具分析了该磁盘组中所有磁盘组头的情况:

从上述对比结果来看,统一磁盘组中;3/4号盘头信息完全一致;而报错的5号磁盘头信息存不一致。

但是实际上我们分析,上述不一致的地方kfdhdb.spfile/kfdhdb.spfflg 的状态应该是正常的。然而根据Oracle mos的如下两篇文档来看确信说明

磁盘存在逻辑不一致的情况,否则不会出现该错误;文档信息如下:

Bug 13480225 -ASM reports:WARNNING:stale disk header detected(Doc ID 13480225.8)
“Warning:stale disk header detected” in ASM alert log(Doc ID 1947021.1)

那么问题最终出现在哪里呢? 据我们后面分析研究;最根本原因在于ASM Smon在进行恢复时,发现COD数据跟该号磁盘涉及信息不匹配导致。

而并不是单纯的说该磁盘头损坏。实际上我们读过该磁盘头的备份信息,确认是完全一致的。因此不得不说是一个逻辑错误。

对于逻辑错误而言,我个人感觉Bug可能性要大一些。

当然最终建议是将该磁盘组drop 然后再添加回磁盘组;如下:

备注:Oracle rac 版本 11.2.0.4 /Linux. 供大家参考.

 

Leave a Reply

You must be logged in to post a comment.