故障描述
近日，由于一套承载着20个pdb的Oracle 19.7 RAC节点1由于硬件故障导致服务器宕机，在服务器更换完主板后发现映射的分布式存储磁盘盘符发生了变化，导致集群在自动启动时找不到voting disk启动失败。报错如下：
故障分析思路
-
查看磁盘是否已经映射
通过比对两边磁盘数量及大小一致。
进一步查看两个节点udev规则，内容如下：
通过查看绑定规则发现，有绑定磁盘名称的也有绑定磁盘分区的，集群的ocr磁盘组对应的盘正是使用的分区名绑定，进一步推断是由于绑定了具体磁盘名称，故障节点磁盘名称发生变化，导致asm无法识别ocr磁盘组对应的磁盘。
故障解决思路
方案1：修改故障节点存储映射磁盘的磁盘名称，通过uuid比对，使名称和正常节点保持一致。
方案2：重新修改故障节点的磁盘udev绑定规则，生成新的磁盘名称。
方案验证
方案1：经过咨询多位资深系统工程师，该方案执行起来较为复杂，修改完重启系统后可能还会变化，需要打相关内核补丁进行固定，最终改方案被否定。
方案2：由于手头有19c RAC测试环境，首先在测试环境进行了验证，验证过程略，验证结果如下：
1.查看asm_disk参数
2.查看原来磁盘名称（两节点一致）
3.停止集群并修改udev绑定规则
4.启动集群并进行磁盘检查
节点2 asm磁盘信息
5.集群状态检查正常（节点1集群也进行了重启测试）
经过验证，该方案可行。
生产环境调整
1.修改udev绑定规则
2.执行udevadmin trigger使规则生效
3.启动集群并查看集群状态
4.启动后该节点磁盘组状态及数据库状态正常，pdb都为读写模式：
5.查看该节点数据库告警日志
通过告警日志发现，数据库hung住了，而此时该节点异常卡顿，命令都无法正常执行，同时发现asm实例已经重启。通过和硬件工程师沟通，该主机4颗CPU，坏了两颗，考虑到硬件故障还未完全解决，当即停掉该节点集群，等待硬件问题解决后再进行启动。
结语
至此，本次故障就处理结束，后续还需要等硬件修复后进行集群启动，另一个正常节点需要寻找停机维护时间，更改原来的udev绑定规则，使两个节点保持一致。
