近日，安图特驻场运维团队收到客户反映，某系统数据库实例无法启动，安图特团队迅速反应，经客户授权后获取root权限，从系统和数据库层面逐一排查问题。在查看过asm的alert之后，发现有磁盘报错。但是在系统层面能够看到每个磁盘，权限属主属组均无异常，并且存储层面的排查也均无问题。

客户方要求重启集群及主机，但问题并没有得到解决。工程师团队迅速反应，查看数据库备份情况，在确认备份完整后，进行了以下排查及操作：

操作系统版本： 红旗AX4 SP4

数据库版本：    Oracle 12c RAC 12.1.0.2

一、故障原因

1、工程师首先尝试打开数据库

分析出原因是DATA这个磁盘组不存在或者没有被mount后；

登陆grid实例查询磁盘组的状态情况：

经查看磁盘组状态是dismount状态，并且这个状态下数值显示为0：

2、由于磁盘组没有被mount，工程师尝试使磁盘组mount

在grid实例下：

此时报错显示磁盘丢失，所以工程师查看了相关的磁盘问题；

3、查看磁盘相关原因

经查看，DATA所用的磁盘是/dev/raw/raw1和/dev/raw/raw3：

但从相关的配置文件和系统层面的属主属组信息来看，磁盘的权限和配置没有任何问题。工程师通过MY ORACLE SUPPORT查看ORA-15042错误的原因，其描述大概为：

1）ASM_DISKSTRING设置不当，导致部分需要的ASM DISK没有被ASM_DISKSTRING反映出来，尝试add disk到某个diskgroup，但是过程中发生了问题或者中断。此时用户对该add的disk 做了dd清理磁盘头，但是实际上diskgroup 的metadata中已经记录了该asm disk；

2）单纯的asm Disk的header被损坏或者彻底丢失，其原因可能是存储I/O故障，也可能是人为失误损坏了asm disk header或OS工具；

查看磁盘的盘头信息后：

最后查看磁盘的盘头信息，发现raw1的盘头已不是member状态。

二、故障处理

从10.2.0.5开始之后的版本，header信息是有额外保护和备份的，用asm metadata的kfed工具来修复盘头：

1、备份现在的盘头的信息到一个txt文件中：

kfed read /dev/raw/raw1 text=/home/oracle/asmdisk_raw1.txt

kfed read /dev/raw/raw3 text=/home/oracle/asmdisk_raw3.txt

2、read两块盘的盘头信息：

从图可以看到raw3的盘头信息是完整的。

而下图中raw1的盘头已经损坏：

3、执行kfed repair命令修复盘头：

kfed repair /dev/raw/raw1 

在数据库中查看磁盘的状态：

 Select PATH,HEADER_STATUS,STATE from v$asm_disk;

最后，盘头的状态恢复。执行起库命令，数据库成功启动。

三、经验总结

本次asm磁盘组盘头故障问题反映了数据容灾备份的重要性，也反映了重启并不能够解决所有问题，出现故障时一定要严谨细致的找到问题的根本；同时要提前做好备份工作，防止因操作失误或系统故障导致数据丢失。

如欲了解更多，请登录安图特官方网站:www.antute.com.cn