某客户的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,基本上全部用光了,还好能够简单修复之一,否则恢复难度和工作量就太大了。无可否认,云和恩墨 依然是国内恢复实力最强的公司,没有之一!

 

发表评论

电子邮件地址不会被公开。 必填项已用*标注