1. 故障概述
早晨8点左右，驻场同事打来电话，反馈Exadata上的ACFS文件系统全部消失，所有的OGG链路全部中断，业务影响范围非常大，几乎所有的核心业务都受到影响。让同事立即检查存储软件服务状态，发现所有存储节点的存储服务运行正常，但cell07和cell09节点各自损坏了一块硬盘。听到这个反馈，心里不由一惊，心想完了，又是一个大事故。
（在采取紧急处理措施之前，先简单交待一下这台Exadata的配置情况：cell01至cell06的所有机械盘做成HIGH冗余的DATA磁盘组；cell07-cell14的所有磁盘做成NORMAL冗余的ARCH磁盘组， 所有数据库的数据文件在DATA磁盘组，所有数据库的归档文件在ARCH磁盘组，同时ARCH磁盘组划分出两个ACFS文件系统，一个 用于数据库备份，一个用于OGG）
目前，ARCH磁盘组处于dismount状态，所有的数据库和OGG都会受到影响，立即让驻场同事通知甲方客户，并尽快切换所有数据库的归档路径，保证数据库的正常运行。至于OGG，暂时肯定是没有什么好办法，只能与客户一起讨论看怎么处理。
2. 故障处理过程
2.1 方案构想
挂断驻场同事的电话后，赶紧给客户领导打了个电话，简单描述了下当前的故障。然后立即开车前往客户现场，与客户一起商讨恢复方案。对于这种Exadata故障，也经历过一两次，基本上心里还是有数的。无非就两种方案，要么就通过AMDU工具抽数，但ACFS中的数据，应该无法使用AMDU工具；要么找专业的存储修复人员，将损坏的硬盘的数据拷贝到新的硬盘中，然后在存储软件层面做一些操作，最终可以正常挂载 ASM磁盘组，基本上不会丢失数据。
2.2 最终方案
到了客户现场，经过商讨，最终放弃了找专业存储修复人员进行硬盘复制的方案，原因是时间周期太长，业务无法停止长达一天的时间。目前，针对 ARCH磁盘组中存放的数据进行分类：
(1). ogg的所有数据都存放在ARCH磁盘组中的ACFS文件系统中，这是非常关键的数据。
(2). 所有数据库的备份数据允许丢失，后期重新备份。
鉴于目前的情况，需要从两方面进行准备。
准备一：做最坏的打算，如果arch磁盘组最终无法修复，OGG所有的数据丢失时，那么就只能重新搭建所有的OGG复制链路。
准备二：想一切的办法，尽力恢复arch磁盘组。
2.3 为了减少业务中断时间，让一部分人员全力配合业务厂商搭建OGG复制链路。
2.4 尽力修复arch磁盘组，即使明知一些操作应该没什么帮助。
（1）、发现9号存储节点上的磁盘损坏严重，磁盘的损坏级别为CRITICAL，而7号存储节点上的磁盘损坏相对较轻，磁盘的损坏级别为WARNING ：Predictive Failure - poor performance。两者是伙伴关系。
| Tue Nov 12 06:25:27 2024 SUCCESS: refreshed membership for 1/0xdf396556 (DG_ARCH) NOTE: Attempting voting file refresh on diskgroup DG_ARCH NOTE: Refresh completed on diskgroup DG_ARCH. No voting file found. …… Tue Nov 12 07:39:16 2024 NOTE: SMON detected lock domain 1 invalid at system inc 38 11/12/24 07:39:15 5630 GCS resources traversed, 0 cancelled WARNING: Read Failed. group:1 disk:47 AU:0 offset:0 size:4096 path:o/192.168.41.233;192.168.41.234/DG_ARCH_CD_03_dm01celadm09 incarnation:0xe96996f5 asynchronous result:'I/O error' subsys:OSS krq:0x7f48cbc953e8 bufp:0x7f48c6fd1000 osderr1:0xc9 osderr2:0x0 Exadata error:'Generic I/O error' IO elapsed time: 4129 usec Time waited on I/O: 0 usec Tue Nov 12 07:39:16 2024 NOTE: cache closing disk 62 of grp 1: (not open) _DROPPED_0062_DG_ARCH ……… Tue Nov 12 07:39:16 2024 NOTE: cache closing disk 62 of grp 1: (not open) _DROPPED_0062_DG_ARCH ERROR: disk 47(DG_ARCH_CD_03_DM01CELADM09) in group 1(DG_ARCH) cannot be offlined because all disks [47(DG_ARCH_CD_03_DM01CELADM09), 62(_DROPPED_0062_DG_ARCH)] with mirrored data would be offline. Tue Nov 12 07:39:16 2024 ERROR: too many offline disks in PST (grp 1) |
（2）、重新拔插9号存储节点上损坏的磁盘，但该磁盘的故障没有变化，磁盘仍然为CRITICAL，ARCH仍然无法挂载。
（3）、关闭9号存储节点，断电静置，彻底释放存储RAID缓存信息。再次加电检测，磁盘故障依旧。
（4）、分析7号存储节点的日志，"WARNING - CONFINEDONLINE, Reason for confinement : threshold for service time exceeded"，从报错日志看出磁盘告警的原因是服务时间超过阈值，所以将该磁盘标记为warning，如果能够找到修改磁盘告警阈值的方法，那么该磁盘就不会被标记为坏盘，从而临时修复磁盘组。但咨询了多位ORACLE原厂售后工程师，原厂售后工程师也未能掌握修改该阈值的方法，最终只能放弃这种尝试。
（5）、修改存储节点的配置文件，将磁盘的状态修改为正常状态，尝试用该方法跳过存储管理软件的检测，最终达到激活磁盘的目的。经过验证，该方法无效，在存储服务启动的过程中，存储管理软件除了读取存储配置文件之外，依然需要扫描磁盘头，当初损坏的磁盘再次被标记为损坏状态。
（6）、经过以上努力，仍然无法用常规的方式挂载arch磁盘组，现在，只能尝试用限制恢复模式挂载arch磁盘组。（alter diskgrou dg_arch mount restricted force for recovery;）经过努力，使用该方式终于成功挂载了arch磁盘组，后续只要能将该磁盘组中的ACFS文件系统挂载到操作系统，就可以把里面的OGG数据拷贝出来。但是，在挂载ACFS文件系统时，挂载失败。经过测试验证，发现ASM磁盘组在限制恢复模式下，无法进行IO操作，这也是ACFS文件系统挂载失败的原因。
（7）、只能继续尝试让arch磁盘组在限制恢复模式下，强制激活损坏的磁盘，（alter griddisk dg_arch_cd_11_dm01celadm07 active;）如果能够强制激活，后续就可以正常挂载arch磁盘组。但是，强制激活磁盘时报错，也就没有办法在限制模式下恢复arch磁盘组。
（8）、至此，做了所有的努力，退出限制恢复模式。抱着试试的想法，用force选项强制挂载arch磁盘组，结果挂载成功，ACFS文件系统也能挂载成功，检查验证发现，有一部分的OGG文件存在损坏，但核心的配置文件都完好无损，后续紧急抢救数据，最终业务恢复。
（9）、为什么最开始没有使用force选项强制挂载arch磁盘组？
To successfully mount with the MOUNT FORCE option, Oracle ASM must be able to find at least one copy of the extents for all of the files in the disk group. In this case, Oracle ASM can successfully mount the disk group, but with potentially reduced redundancy.
从官方文档也可以看出，moount force不是包治百病的命令。在磁盘组中至少要有一份完整的数据，才能mount成功，当前在不同的failgroup中已经丢失了两块磁盘，并且这两块磁盘是partnership关系，理论上，mount force应该也无法挂载成功。 经过上面的各种折腾尝试，最后也mount成功。
3. 后续
这种使用了多年的Exadata，如果是Normal磁盘组，一定要做好备份，并且备份必须放在Exadata以外的设备上。
