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

我们的文章会在微信公众号IT民工的龙马人生和博客网站( www.htz.pw )同步更新 ，欢迎关注收藏，也欢迎大家转载，但是请在文章开始地方标注文章出处，谢谢！
由于博客中有大量代码，通过页面浏览效果更佳。

• 对比节点间多路径设备，定位故障节点
  首先，我们在两个节点上分别检查了多路径设备的状态，以判断问题是共享存储本身的问题还是单个节点的问题。
  
  
  
  • 在正常节点 prod01 上执行 multipath -ll，可以看到名为 ora_2 的设备：
    1. [root@prod01 ~]# fdisk -l|grep "10.7"
    2. WARNING: fdisk GPT support is currently new, and therefore in an experimental phase. Use at your own discretion.
    3. Disk /dev/sdc: 10.7 GB, 10737418240 bytes, 20971520 sectors
    4. Disk /dev/sdg: 10.7 GB, 10737418240 bytes, 20971520 sectors
    5. Disk /dev/sdd: 10.7 GB, 10737418240 bytes, 20971520 sectors
    6. Disk /dev/sdh: 10.7 GB, 10737418240 bytes, 20971520 sectors
    7. Disk /dev/sdf: 10.7 GB, 10737418240 bytes, 20971520 sectors
    8. Disk /dev/sde: 10.7 GB, 10737418240 bytes, 20971520 sectors
    9. Disk /dev/mapper/ora_5: 10.7 GB, 10737418240 bytes, 20971520 sectors
    10. Disk /dev/mapper/ora_2: 10.7 GB, 10737418240 bytes, 20971520 sectors
    11. Disk /dev/mapper/ora_3: 10.7 GB, 10737418240 bytes, 20971520 sectors
    12. Disk /dev/mapper/ora_4: 10.7 GB, 10737418240 bytes, 20971520 sectors
    13. Disk /dev/mapper/ora_6: 10.7 GB, 10737418240 bytes, 20971520 sectors
    14. Disk /dev/mapper/ora_1: 10.7 GB, 10737418240 bytes, 20971520 sectors
    15. [root@prod01 ~]# multipath -ll|grep "ora"
    16. ora_3 (36000c294d2a3b06eb9f13d73cfeb4342) dm-4 VMware  ,Virtual disk   
    17. ora_2 (36000c2940c87e09a104cb79a07733e93) dm-3 VMware  ,Virtual disk   
    18. ora_1 (36000c2927c98f4f4d3bec35c4a21fe5a) dm-8 VMware  ,Virtual disk   
    19. ora_6 (36000c293ddf77089da001564c5a24265) dm-7 VMware  ,Virtual disk   
    20. ora_5 (36000c295c3124ab4dc2b9ba7f1897846) dm-2 VMware  ,Virtual disk   
    21. ora_4 (36000c295de1691d24c3bd8107ee0109d) dm-5 VMware  ,Virtual disk  

    复制代码
    该设备 ora_2 的 WWID 为 36000c2940c87e09a104cb79a07733e93。
    
  • 在问题节点 prod02 上执行 multipath -ll，输出中缺失了 ora_2 设备：
    1. [root@prod02 ~]# multipath -ll|grep "ora"
    2. ora_3 (36000c294d2a3b06eb9f13d73cfeb4342) dm-2 VMware  ,Virtual disk
    3. ora_1 (36000c2927c98f4f4d3bec35c4a21fe5a) dm-4 VMware  ,Virtual disk
    4. ora_6 (36000c293ddf77089da001564c5a24265) dm-6 VMware  ,Virtual disk
    5. ...

    复制代码
    分析结论： 共享磁盘本身没有问题，故障点明确位于 prod02 节点，是该节点未能正确识别并创建 ora_2 多路径设备。
    
  
  
• 在 prod02 节点上识别底层物理设备
  既然多路径设备未创建，下一步是确认其对应的物理磁盘在 prod02 节点上是否存在。我们通过 scsi_id 工具扫描所有裸盘的 WWID。
  
  
  
  • 执行以下命令获取所有 sd 磁盘的唯一标识符：
    1. [root@prod02 ~]# ls -v -1c /dev/sd*[!0-9] | xargs -I {} sh -c 'echo -n "{} : " ; /lib/udev/scsi_id --whitelisted --device={}'
    2. /dev/sda : 36000c294592edb8af36130422a6bfcdd
    3. ...
    4. /dev/sdh : 36000c297c9a1518631cc1b0f7b2b060c
    5. /dev/sdi : 36000c2940c87e09a104cb79a07733e93

    复制代码
    分析结论： 从输出中可以清晰地看到，丢失的 WWID 36000c2940c87e09a104cb79a07733e93 在 prod02 节点上对应的物理设备是 /dev/sdi。这证明物理磁盘是存在的，问题出在从物理盘到多路径设备的映射环节。
    
  
  
• 检查多路径配置文件，定位根本原因
  物理设备存在，但多路径聚合设备没有被创建，最大的嫌疑就是 multipath 服务的配置问题。我们检查了 prod02 节点的 /etc/multipath.conf 文件。
  
  
  
  • 通过 grep 命令在配置文件中搜索 sdi 相关的条目：
    1. [root@prod02 ~]# cat /etc/multipath.conf|grep "sdi"
    2.                devnode "^sdi"

    复制代码
    根本原因： 这条 devnode "^sdi" 配置的作用是将 /dev/sdi 设备加入到了多路径的黑名单中。这导致 multipathd 服务在扫描设备时会主动忽略 /dev/sdi，从而无法为其创建对应的多路径聚合设备。这正是 ora_2 在 prod02 上消失的直接原因。
    
  
  

• 修正多路径配置:
  
  
  
  • （隐含步骤）编辑 prod02 节点的 /etc/multipath.conf 文件，删除或注释掉 devnode "^sdi" 这一行，解除对 /dev/sdi 设备的屏蔽。
    
  
  
• 重新加载 multipath 配置:
  
  
  
  • 在 prod02 节点以 root 用户执行命令，强制 multipathd 服务重新加载配置并扫描设备。日志显示 ora_2 被成功创建 (create: ora_2 ...)。
    1. [root@prod02 ~]# multipath -r
    2. ...
    3. create: ora_2 (36000c2940c87e09a104cb79a07733e93) undef VMware  ,Virtual disk
    4. size=10G features='0' hwhandler='0' wp=undef
    5. `-+- policy='service-time 0' prio=1 status=undef
    6.   `- 0:0:8:0 sdi                8:128  undef ready running
    7. ...
    8. [root@prod02 ~]# multipathd -k"reconfigure"
    9. ok

    复制代码
  
  
• 添加磁盘回 ASM 磁盘组:
  
  
  
  • 确认 /dev/mapper/ora_2 设备已在 prod02 节点上成功创建后，以 grid 用户身份登录数据库，执行 SQL 命令将磁盘加回 ASM。
    1. alter diskgroup RAC19C_OCR add failgroup RAC19C_OCR_0001 disk '/dev/mapper/ora_2' force;

    复制代码
    FORCE 关键字用于强制添加一个之前属于该磁盘组的磁盘。
    
  
  
• 验证恢复结果:
  
  
  
  • 使用 asmcmd lsdsk -kG RAC19C_OCR 检查，确认磁盘组中的所有磁盘状态正常，_DROPPED_ 磁盘消失。
    1. SQL> !asmcmd lsdsk -kG RAC19C_OCR
    2. Total_MB  Free_MB  OS_MB  Name             Failgroup        ...   Path
    3.    10240     9884  10240  RAC19C_OCR_0003  RAC19C_OCR_0001  ...   /dev/mapper/ora_2
    4.    10240     9880  10240  RAC19C_OCR_0002  RAC19C_OCR_0002  ...   /dev/mapper/ora_4
    5.    10240     9872  10240  RAC19C_OCR_0000  RAC19C_OCR_0000  ...   /dev/mapper/ora_6

    复制代码
  • 使用 crsctl query css votedisk 检查，确认所有3个投票磁盘均处于 ONLINE 状态，并且包含了新加回的 /dev/mapper/ora_2。
    1. SQL> !crsctl query css votedisk
    2. ##  STATE    File Universal Id                File Name Disk group
    3. --  -----    -----------------                --------- ---------
    4. 1. ONLINE   019e36c3d64e4fdabf7fa75f6b3a57e4 (/dev/mapper/ora_6) [RAC19C_OCR]
    5. 2. ONLINE   7ce9cb70316d4f3cbf713af8c8ecb3b7 (/dev/mapper/ora_4) [RAC19C_OCR]
    6. 3. ONLINE   106ef377d1c64f40bfb039a3411fc317 (/dev/mapper/ora_2) [RAC19C_OCR]
    7. Located 3 voting disk(s).

    复制代码
  
  

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