根本原因是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/<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 配置有误 —— 这类问题不会报错，只会静默跳过。
