我们的文章会在微信公众号IT民工的龙马人生和博客网站( www.htz.pw )同步更新 ，欢迎关注收藏，也欢迎大家转载，但是请在文章开始地方标注文章出处，谢谢！
由于博客中有大量代码，通过页面浏览效果更佳。
故障背景
近期，为备考 Oracle ADG (Active Data Guard) 相关认证，我与同事需要共同验证一套题库的准确性。为此，我启动了个人实验环境中的五台虚拟机，搭建了一套完整的 Oracle 19c RAC + Data Guard 环境供团队使用。在环境交付后不久，一位同事反馈，第一套 RAC 集群的 prod02 节点其 OCR 磁盘组中存在磁盘丢失的情况。
考虑到该实验环境此前一直运行稳定，出现此问题显得较为蹊跷。为了不影响团队的验证进度，我立即远程接入该环境进行排查，并在2分钟内快速定位和解决了问题。本报告旨在详细记录并复盘此次故障的排-查过程与解决方案。
1. 故障现象
巡检时发现，Oracle 集群 RAC19C_OCR ASM 磁盘组中一个磁盘被标记为 _DROPPED_，状态异常。通过 ASM 命令 lsdsk -kG RAC19C_OCR 查看，可以清晰地看到 RAC19C_OCR_0001 故障组的磁盘已丢失，这直接导致 OCR 磁盘组的冗余度降低，对集群的稳定性和高可用性构成潜在威胁。
ASMCMD> lsdsk -kG RAC19C_OCR
Total_MB Free_MB OS_MB Name Failgroup Site_Name Site_GUID Site_Status Failgroup_Type Library Label Failgroup_Label Site_Label UDID Product Redund Path
10240 10060 0 _DROPPED_0001_RAC19C_OCR RAC19C_OCR_0001 00000000000000000000000000000000 REGULAR System UNKNOWN
10240 9820 10240 RAC19C_OCR_0002 RAC19C_OCR_0002 00000000000000000000000000000000 REGULAR System UNKNOWN /dev/mapper/ora_4
10240 9820 10240 RAC19C_OCR_0000 RAC19C_OCR_0000 00000000000000000000000000000000 REGULAR System UNKNOWN /dev/mapper/ora_6
2. 分析过程
本次故障排查遵循从上至下、层层递进的原则，从 ASM 层逐步排查到操作系统和存储层，以下是详细的分析步骤及日志证据。
-
对比节点间多路径设备，定位故障节点
首先，我们在两个节点上分别检查了多路径设备的状态，以判断问题是共享存储本身的问题还是单个节点的问题。
-
在正常节点
prod01上执行multipath -ll，可以看到名为ora_2的设备：[root@prod01 ~]# fdisk -l|grep "10.7" WARNING: fdisk GPT support is currently new, and therefore in an experimental phase. Use at your own discretion. Disk /dev/sdc: 10.7 GB, 10737418240 bytes, 20971520 sectors Disk /dev/sdg: 10.7 GB, 10737418240 bytes, 20971520 sectors Disk /dev/sdd: 10.7 GB, 10737418240 bytes, 20971520 sectors Disk /dev/sdh: 10.7 GB, 10737418240 bytes, 20971520 sectors Disk /dev/sdf: 10.7 GB, 10737418240 bytes, 20971520 sectors Disk /dev/sde: 10.7 GB, 10737418240 bytes, 20971520 sectors Disk /dev/mapper/ora_5: 10.7 GB, 10737418240 bytes, 20971520 sectors Disk /dev/mapper/ora_2: 10.7 GB, 10737418240 bytes, 20971520 sectors Disk /dev/mapper/ora_3: 10.7 GB, 10737418240 bytes, 20971520 sectors Disk /dev/mapper/ora_4: 10.7 GB, 10737418240 bytes, 20971520 sectors Disk /dev/mapper/ora_6: 10.7 GB, 10737418240 bytes, 20971520 sectors Disk /dev/mapper/ora_1: 10.7 GB, 10737418240 bytes, 20971520 sectors [root@prod01 ~]# multipath -ll|grep "ora" ora_3 (36000c294d2a3b06eb9f13d73cfeb4342) dm-4 VMware ,Virtual disk ora_2 (36000c2940c87e09a104cb79a07733e93) dm-3 VMware ,Virtual disk ora_1 (36000c2927c98f4f4d3bec35c4a21fe5a) dm-8 VMware ,Virtual disk ora_6 (36000c293ddf77089da001564c5a24265) dm-7 VMware ,Virtual disk ora_5 (36000c295c3124ab4dc2b9ba7f1897846) dm-2 VMware ,Virtual disk ora_4 (36000c295de1691d24c3bd8107ee0109d) dm-5 VMware ,Virtual disk该设备
ora_2的 WWID 为36000c2940c87e09a104cb79a07733e93。 -
在问题节点
prod02上执行multipath -ll，输出中缺失了ora_2设备：[root@prod02 ~]# multipath -ll|grep "ora" ora_3 (36000c294d2a3b06eb9f13d73cfeb4342) dm-2 VMware ,Virtual disk ora_1 (36000c2927c98f4f4d3bec35c4a21fe5a) dm-4 VMware ,Virtual disk ora_6 (36000c293ddf77089da001564c5a24265) dm-6 VMware ,Virtual disk ...分析结论： 共享磁盘本身没有问题，故障点明确位于
prod02节点，是该节点未能正确识别并创建ora_2多路径设备。
-
-
在
prod02节点上识别底层物理设备既然多路径设备未创建，下一步是确认其对应的物理磁盘在
prod02节点上是否存在。我们通过scsi_id工具扫描所有裸盘的 WWID。-
执行以下命令获取所有
sd磁盘的唯一标识符：[root@prod02 ~]# ls -v -1c /dev/sd*[!0-9] | xargs -I {} sh -c 'echo -n "{} : " ; /lib/udev/scsi_id --whitelisted --device={}' /dev/sda : 36000c294592edb8af36130422a6bfcdd ... /dev/sdh : 36000c297c9a1518631cc1b0f7b2b060c /dev/sdi : 36000c2940c87e09a104cb79a07733e93分析结论： 从输出中可以清晰地看到，丢失的 WWID
36000c2940c87e09a104cb79a07733e93在prod02节点上对应的物理设备是/dev/sdi。这证明物理磁盘是存在的，问题出在从物理盘到多路径设备的映射环节。
-
-
检查多路径配置文件，定位根本原因
物理设备存在，但多路径聚合设备没有被创建，最大的嫌疑就是
multipath服务的配置问题。我们检查了prod02节点的/etc/multipath.conf文件。-
通过
grep命令在配置文件中搜索sdi相关的条目：[root@prod02 ~]# cat /etc/multipath.conf|grep "sdi" devnode "^sdi"根本原因： 这条
devnode "^sdi"配置的作用是将/dev/sdi设备加入到了多路径的黑名单中。这导致multipathd服务在扫描设备时会主动忽略/dev/sdi，从而无法为其创建对应的多路径聚合设备。这正是ora_2在prod02上消失的直接原因。
-
3. 解决方案
-
修正多路径配置:
- （隐含步骤）编辑
prod02节点的/etc/multipath.conf文件，删除或注释掉devnode "^sdi"这一行，解除对/dev/sdi设备的屏蔽。
- （隐含步骤）编辑
-
重新加载 multipath 配置:
-
在
prod02节点以root用户执行命令，强制multipathd服务重新加载配置并扫描设备。日志显示ora_2被成功创建 (create: ora_2 ...)。[root@prod02 ~]# multipath -r ... create: ora_2 (36000c2940c87e09a104cb79a07733e93) undef VMware ,Virtual disk size=10G features='0' hwhandler='0' wp=undef `-+- policy='service-time 0' prio=1 status=undef `- 0:0:8:0 sdi 8:128 undef ready running ... [root@prod02 ~]# multipathd -k"reconfigure" ok
-
-
添加磁盘回 ASM 磁盘组:
-
确认
/dev/mapper/ora_2设备已在prod02节点上成功创建后，以grid用户身份登录数据库，执行 SQL 命令将磁盘加回 ASM。alter diskgroup RAC19C_OCR add failgroup RAC19C_OCR_0001 disk '/dev/mapper/ora_2' force;FORCE关键字用于强制添加一个之前属于该磁盘组的磁盘。
-
-
验证恢复结果:
-
使用
asmcmd lsdsk -kG RAC19C_OCR检查，确认磁盘组中的所有磁盘状态正常，_DROPPED_磁盘消失。SQL> !asmcmd lsdsk -kG RAC19C_OCR Total_MB Free_MB OS_MB Name Failgroup ... Path 10240 9884 10240 RAC19C_OCR_0003 RAC19C_OCR_0001 ... /dev/mapper/ora_2 10240 9880 10240 RAC19C_OCR_0002 RAC19C_OCR_0002 ... /dev/mapper/ora_4 10240 9872 10240 RAC19C_OCR_0000 RAC19C_OCR_0000 ... /dev/mapper/ora_6 -
使用
crsctl query css votedisk检查，确认所有3个投票磁盘均处于ONLINE状态，并且包含了新加回的/dev/mapper/ora_2。SQL> !crsctl query css votedisk ## STATE File Universal Id File Name Disk group -- ----- ----------------- --------- --------- 1. ONLINE 019e36c3d64e4fdabf7fa75f6b3a57e4 (/dev/mapper/ora_6) [RAC19C_OCR] 2. ONLINE 7ce9cb70316d4f3cbf713af8c8ecb3b7 (/dev/mapper/ora_4) [RAC19C_OCR] 3. ONLINE 106ef377d1c64f40bfb039a3411fc317 (/dev/mapper/ora_2) [RAC19C_OCR] Located 3 voting disk(s).
-
4. 建议与总结
总结:
本次故障是由于 RAC 节点 prod02 上的多路径配置文件 /etc/multipath.conf 存在错误配置，将 OCR 磁盘组的一个物理设备 (/dev/sdi) 错误地加入黑名单。这导致该节点无法识别对应的多路径设备 (/dev/mapper/ora_2)，进而造成 ASM 磁盘组发生磁盘丢失。通过详细的日志分析，我们精准定位了故障根源，并快速修正了配置，最终成功将磁盘加回 ASM 磁盘组，恢复了集群投票磁盘的正常冗余。
建议:
- 配置一致性检查: 应将 RAC 集群中所有节点的关键配置文件（如
/etc/multipath.conf、/etc/sysctl.conf等）纳入常态化的一致性检查，防止因单点配置错误引发集群问题。建议使用 Ansible、SaltStack 等自动化工具来统一部署和校验配置。 - 标准化变更流程: 在进行任何存储、网络或系统级别的变更时，必须遵循标准化的操作流程。变更后，必须在所有相关节点上进行全面验证，确保共享资源（如磁盘）的可见性和配置正确性。
- 加强监控和告警: 完善监控体系，除了监控 ASM 磁盘组状态外，还应加入对底层多路径设备状态的监控。当任一节点出现设备路径丢失或状态异常时，应能立即触发告警，以便在问题升级前及时介入。
- 文档化管理: 对
/etc/multipath.conf等核心配置的每一次变更，都应有详细的文档记录，包括变更原因、时间、负责人和回滚方案，这对于快速追溯和定位问题至关重要。
——————作者介绍———————–
姓名：黄廷忠
现就职：Oracle中国高级服务团队
曾就职：OceanBase、云和恩墨、东方龙马等
电话、微信、QQ：18081072613
个人博客: (http://www.htz.pw)
CSDN地址: (https://blog.csdn.net/wwwhtzpw)
博客园地址: (https://www.cnblogs.com/www-htz-pw)
故障处理：2分钟处理Oracle RAC中OCR磁盘组丢失磁盘的故障：等您坐沙发呢！