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