某银行客户一套1.4TB ASM(RAC) 磁盘损坏恢复小记

这周折腾了2天的时间帮客户成功恢复了一套近1.4TB的10.2.0.5 RAC(ASM). 该库在3月4号直接crash了。

大家可以看到,该库在开始报错读取redo,controlfile报错,本质原因是DISKGROUP dismount了,信息如下:

数据库实例挂了之后,我们来看下ASM实例的alert log信息,如下:

大家可以看到,ASM报了一个ORA-15081错误,在该错误之前是报对其中一个盘/dev/raw/raw5的IO操作错误。
细心的朋友可以看到,这里由于IO 操作异常后,该disk被offline了。最后磁盘组无法mount。

我们测试使用kfed read无法读取该disk,dd也无法操作。但是却可以直接dd 该disk对应的物理盘。

磁盘组无法mount,从其中trace来看显然是磁盘头损坏,如下:

大家知道Oracle ASM 10.2.0.5版本开始会对ASM disk header 进行自动备份,如果如果仅仅是盘头
损坏那么恢复是很easy的。但是其实并不是这么简单,通过dd判断,该盘的前面几个block其实被损坏。

最后我们通过ODU 直接将数据文件从磁盘拷贝到文件系统,然后起库,最后完成整个恢复过程。

备注:在恢复过程中,发现ODU无法直接拷贝test201402.dbf 这样的文件,然而通过检查

asm alias directory发现,其实是完好的,这里可能odu处理还有点小问题,我们通过手工将该元数据

的AU 读取出来,然后匹配将剩下的文件全部抽取出来了,包括redo,controlfile,直接顺利打开数据库。

最终经过我们的抢救,使用我们的数据库恢复软件成功帮助客户恢复了数据!当遇到类似问题时,请记得一定要保持现场,尽量不要做其他操作,防止进一步恶化。

某客户的50TB 超大型Oracle数据库恢复案例

某客户50 TB的ASM发生故障,经过合力拯救,恢复正常,在此简单记录一下!实际上最后发现比我想象中的简单的多。如下是关于该故障的详细描述情况。

–db alert log信息

从db的alert log来看,是出现了IO异常,导致lgwr进程写日志,最后lgwr进程强行终止数据库实例.很明显,这里我们需要分析为什么lgwr进程无法写日志呢 ? 接着查看asm日志如下:

从上述信息来看,很明显是因为asm 磁盘组中的32号盘出现IO问题,导致磁盘组被强制offline,最后数据库实例也crash。后面客户尝试手工mount diskgroup 发现报如下类似错误:

这个错误极有可能是某个bug,在安装该patch 之后,最后再次尝试mount,发现仍然报错。不过错误已经发生改变:

可以看出,Oracle ASM在mount的时候,需要进行crash recovery,其中的检查点位置就是6295.7329;检查trace发现检查点所读取的位置如下:

可以看到,oracle需要读取32号磁盘的第1638611号AU,10g AU默认是1M,那么这个位置大致是1.6T的样子,实际上这个checkpoint的位置,我们很容易找到,这里通过kfed可以直接读取,如下:

最后客户经过各种尝试之后,仍然在mount 磁盘组的时候报如下的错误:

关于这一点跟Oracle MOS文档understanding and fixing errors ORA-600 [kfcChkAio01] and ORA-15196(Doc ID 757529.1)完全一致,因此最后我们建议客户根据该文档的描述,处理即可,实际上处理的方式很简单,该文档提供了提供shell脚本,只需要修改其中的块号即可。处理完毕之后,成功mount 磁盘组如下:

最后我们回过头来解释一下,为什么会出现这样的情况呢? 实际上,根本原因在于,客户在之前添加磁盘的时候操作不规范,如下:

前面出问题的disk 就是第32号盘,其大小是1677721M,实际上我们检查发现该磁盘的物理大小是1638400M。
换句话将,在添加磁盘的时候,写了一个比较大的数值,让Oracle以为是这么大,然而实际上并没有这么大。当然,这也只能说明是Oracle 10g 版本中对于asm 的校验不够严格。
所以,问题很明确,报错的AU 编号1638611是大于 1638400的,所以这是一个不存在的位置,因此asm crash了。

备注:客户这里asm diskgroup 一共用了36个盘,每个盘1.6TB,大约53TB,基本上全部用光了,还好能够简单修复之一,否则恢复难度和工作量就太大了。无可否认,云和恩墨 依然是国内恢复实力最强的公司,没有之一!