故障背景近期为备考 Oracle ADG (Active Data Guard) 相关认证我与同事需要共同验证一套题库的准确性。为此我启动了个人实验环境中的五台虚拟机搭建了一套完整的 Oracle 19c RAC Data Guard 环境供团队使用。在环境交付后不久一位同事反馈第一套 RAC 集群的prod02节点其 OCR 磁盘组中存在磁盘丢失的情况。考虑到该实验环境此前一直运行稳定出现此问题显得较为蹊跷。为了不影响团队的验证进度我立即远程接入该环境进行排查并在2分钟内快速定位和解决了问题。本报告旨在详细记录并复盘此次故障的排-查过程与解决方案。1. 故障现象巡检时发现Oracle 集群RAC19C_OCRASM 磁盘组中一个磁盘被标记为_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_62. 分析过程本次故障排查遵循从上至下、层层递进的原则从 ASM 层逐步排查到操作系统和存储层以下是详细的分析步骤及日志证据。对比节点间多路径设备定位故障节点首先我们在两个节点上分别检查了多路径设备的状态以判断问题是共享存储本身的问题还是单个节点的问题。在正常节点prod01上执行multipath -ll可以看到名为ora_2的设备[rootprod01 ~]# 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 [rootprod01 ~]# 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设备[rootprod02 ~]# 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磁盘的唯一标识符[rootprod02 ~]# 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分析结论从输出中可以清晰地看到丢失的 WWID36000c2940c87e09a104cb79a07733e93在prod02节点上对应的物理设备是/dev/sdi。这证明物理磁盘是存在的问题出在从物理盘到多路径设备的映射环节。检查多路径配置文件定位根本原因物理设备存在但多路径聚合设备没有被创建最大的嫌疑就是multipath服务的配置问题。我们检查了prod02节点的/etc/multipath.conf文件。通过grep命令在配置文件中搜索sdi相关的条目[rootprod02 ~]# 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 ...)。[rootprod02 ~]# multipath -r ... create: ora_2 (36000c2940c87e09a104cb79a07733e93) undef VMware ,Virtual disk size10G features0 hwhandler0 wpundef -- policyservice-time 0 prio1 statusundef - 0:0:8:0 sdi 8:128 undef ready running ... [rootprod02 ~]# multipathd -kreconfigure 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等核心配置的每一次变更都应有详细的文档记录包括变更原因、时间、负责人和回滚方案这对于快速追溯和定位问题至关重要。