Oracle 11g RAC重启多路径软件后报错，如何重新扫描SCSI总线并重启ASM？

本文共计870个文字，预计阅读时间需要4分钟。

相关专题：

oracle 11g rac节点在多路径软件（如 multipathd）重启后报错、asm无法启动，根本原因不是“扫描没做”，而是共享磁盘设备名映射关系丢失 + asm磁盘头未被重新识别。单纯执行 rescan-scsi-bus.sh 或 echo 1 > /sys/class/scsi_device/*/device/rescan 并不能恢复asm对 voting disk 和 ocr 磁盘的感知 —— 因为这些磁盘依赖的是稳定的多路径设备（如 /dev/mapper/mpathb），而 multipathd 重启会清空当前映射，旧的 device mapper 节点消失，新节点虽存在但未被 asm 自动重发现。

---

multipathd 重启后 ASM 报 ORA-15032 / ORA-15017 的真实链路

• multipathd 服务重启 → 所有 /dev/mapper/<em></em> 设备被移除（dm- 设备节点销毁）
• 内核 SCSI 层仍保留底层路径（如 /dev/sdb），但多路径层未重建映射 → ls -l /dev/mapper/ 显示为空或仅剩本地盘
• ASM 实例启动时调用 libasm 扫描磁盘，只认配置中指定的设备路径（通常是 /dev/mapper/*）→ 扫不到 voting disk → 启动失败，报错类似：

  ORA-15032: not all alterations performed ORA-15017: diskgroup "OCR_VOTE" cannot be mounted ORA-15063: ASM discovered an insufficient number of disks

• 此时即使手动运行 rescan-scsi-bus.sh，也只是让内核重新识别底层 LUN，不触发 multipath 重建 → /dev/mapper/* 依然不存在

---

必须按顺序执行的三步修复动作

• 确保 multipathd 已运行且配置正确：systemctl status multipathd；检查 /etc/multipath.conf 中 devices 块的 getuid_callout 是否匹配当前 OS 版本（例如 RHEL6.5 必须用 --whitelisted --device=/dev/%n，RHEL5 用旧版 scsi_id -g -u -s）
• 强制重建多路径映射：multipath -v2（不是 -F，后者会清空所有映射）；验证输出中是否列出你的 OCR/voting 盘，且状态为 active ready running
• 重新加载 ASM 磁盘发现规则（关键！）：udevadm trigger --subsystem-match=mpath 或直接 udevadm settle，确保 udev 创建了新的 /dev/mapper/* 节点并设置好权限（属主 grid:asmadmin，权限 0660）

---

容易被忽略的两个硬性前提

• ORACLEASM 服务（即 oracleasm）在 11g RAC 中已弃用，不要尝试运行 oracleasm scandisks —— 这是 10g 时代的遗留操作，对基于 UDEV + multipath 的 11gR2+ 架构完全无效，还会干扰设备节点生成
• ASM 实例启动前，必须确认 diskstring 参数指向的是多路径设备路径，而非底层 SCSI 设备。检查方式：sqlplus / as sysasm → show parameter diskstring；典型值应为 '/dev/mapper/ocr_vot<em>','/dev/mapper/data</em>'，而非 '/dev/sd*'

复杂点在于：这个过程没有“一键修复”命令，每一步的输出都必须人工验证是否生效；尤其是 multipath -v2 输出里看不到目标盘，就说明 multipath.conf 的 WWID 匹配规则或 storage vendor 配置有误 —— 这类问题不会报错，只会静默跳过。