故障处理：2分钟处理Oracle RAC中OCR磁盘组丢失磁盘的故障

我们的文章会在微信公众号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   Path10240    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_410240     9820  10240  RAC19C_OCR_0000           RAC19C_OCR_0000             00000000000000000000000000000000               REGULAR         System                                                      UNKNOWN  /dev/mapper/ora_6

2. 分析过程

本次故障排查遵循从上至下、层层递进的原则，从 ASM 层逐步排查到操作系统和存储层，以下是详细的分析步骤及日志证据。

1. 对比节点间多路径设备，定位故障节点

   首先，我们在两个节点上分别检查了多路径设备的状态，以判断问题是共享存储本身的问题还是单个节点的问题。

   • 在正常节点 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 多路径设备。

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。这证明物理磁盘是存在的，问题出在从物理盘到多路径设备的映射环节。

3. 检查多路径配置文件，定位根本原因

   物理设备存在，但多路径聚合设备没有被创建，最大的嫌疑就是 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. 解决方案

1. 修正多路径配置:

   • （隐含步骤）编辑 prod02 节点的 /etc/multipath.conf 文件，删除或注释掉 devnode "^sdi" 这一行，解除对 /dev/sdi 设备的屏蔽。

2. 重新加载 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
     

3. 添加磁盘回 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 关键字用于强制添加一个之前属于该磁盘组的磁盘。

4. 验证恢复结果:

   • 使用 asmcmd lsdsk -kG RAC19C_OCR 检查，确认磁盘组中的所有磁盘状态正常，_DROPPED_ 磁盘消失。

     SQL> !asmcmd lsdsk -kG RAC19C_OCR
     Total_MB  Free_MB  OS_MB  Name             Failgroup        ...   Path10240     9884  10240  RAC19C_OCR_0003  RAC19C_OCR_0001  ...   /dev/mapper/ora_210240     9880  10240  RAC19C_OCR_0002  RAC19C_OCR_0002  ...   /dev/mapper/ora_410240     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 磁盘组，恢复了集群投票磁盘的正常冗余。

建议:

1. 配置一致性检查: 应将 RAC 集群中所有节点的关键配置文件（如 /etc/multipath.conf、/etc/sysctl.conf 等）纳入常态化的一致性检查，防止因单点配置错误引发集群问题。建议使用 Ansible、SaltStack 等自动化工具来统一部署和校验配置。
2. 标准化变更流程: 在进行任何存储、网络或系统级别的变更时，必须遵循标准化的操作流程。变更后，必须在所有相关节点上进行全面验证，确保共享资源（如磁盘）的可见性和配置正确性。
3. 加强监控和告警: 完善监控体系，除了监控 ASM 磁盘组状态外，还应加入对底层多路径设备状态的监控。当任一节点出现设备路径丢失或状态异常时，应能立即触发告警，以便在问题升级前及时介入。
4. 文档化管理: 对 /etc/multipath.conf 等核心配置的每一次变更，都应有详细的文档记录，包括变更原因、时间、负责人和回滚方案，这对于快速追溯和定位问题至关重要。

------------------作者介绍-----------------------
姓名：黄廷忠
现就职：Oracle中国高级服务团队
曾就职：OceanBase、云和恩墨、东方龙马等
电话、微信、QQ：18081072613
个人博客: (http://www.htz.pw)
CSDN地址: (https://blog.csdn.net/wwwhtzpw)
博客园地址: (https://www.cnblogs.com/www-htz-pw)

---