为什么Oracle 11g RAC在多路径软件重启后报错_重新扫描SCSI总线并重启ASM-Oracle-PHP中文网

根本原因是multipathd重启导致多路径设备映射丢失，ASM无法识别OCR/voting磁盘；需依次执行：确认multipathd运行及配置正确、multipath -v2重建映射、udevadm trigger触发设备节点生成。

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/ 设备被移除（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','/dev/mapper/data'，而非 '/dev/sd*'