在 Oracle RAC 环境中，两个节点的 multipath -ll 输出必须完全一致：包括设备名称、路径数量以及每条路径的状态都要保持相同。否则 RAC ASM 可能无法正确识别共享磁盘，进而导致磁盘组挂载失败，甚至出现 OCR 丢失等严重问题。
直接检查 multipath -ll 输出是否一致
对比两个节点上的多路径设备列表是否完全一致，是排查 Oracle RAC 多路径存储异常时最基础、也最容易忽略的一步。常见问题包括：一个节点能够看到 ora_2、ora_4，而另一个节点只识别到 ora_2；或者虽然设备名一致，但底层路径数量不同，例如一侧显示 4 条路径，另一侧却只有 2 条。
执行命令前，先确认当前用户具备足够权限：su - root，然后运行：
multipath -ll | grep -E "(ora_|size=|status=)"
重点核对以下三项：
- 设备名（如
ora_2）在两个 RAC 节点上是否都存在，且命名完全一致 - 每个 multipath 设备对应的路径数量是否相同（即
-+-下方挂载的 SCSI 设备行数） - 每条路径状态是否均为
active ready running，而不是failed、ghost等异常状态
检查 iSCSI 会话是否全部登录成功
iscsiadm -m session 显示的是当前实际处于活跃状态的 iSCSI 连接，并不是“已经配置”就代表“已经连接”。在 Oracle RAC 架构下，每个节点都必须通过多个网络接口（通常是两块网卡分别连接不同交换机）登录到同一个 target，否则 multipath 无法建立完整的冗余路径。
典型异常现象如下：
iscsiadm -m session没有任何返回，说明当前根本没有登录 target- 只看到 1 条 session，说明仅使用了一条链路，multipath 会退化成单路径模式
- session 虽然存在，但
iscsiadm -m node -P 1 | grep "State"显示State: NON-EXISTS，表示节点配置并未真正生效
补救操作（以下以 target IQN 为例）：
iscsiadm -m node -T iqn.2026-07.com.starwind:rac-target -p 192.168.10.10:3260 --login
iscsiadm -m node -T iqn.2026-07.com.starwind:rac-target -p 192.168.10.11:3260 --login
务必确认两个 IP（对应两条物理链路）都执行了 --login，并且返回结果中包含 Login to [iface: default, target: ..., portal: ...] successful.，这样才能说明登录成功。
验证 udev 规则是否生成稳定设备名
ASM 不识别像 /dev/sdb 这类容易变化的设备名，更依赖 /dev/mapper/ora_2 这样的 multipath 稳定设备名。如果 udev 规则未生效，或者存在规则冲突，系统重启后设备可能变成 /dev/dm-3 这类编号名称，导致 ASM 无法正常识别共享磁盘。
建议重点检查以下内容：
ls -l /dev/mapper/ | grep ora，确认设备文件是否存在，且权限是否为brw-rw----udevadm info --name=/dev/mapper/ora_2 | grep ID_SERIAL，确认输出的序列号是否与multipath -ll中对应设备的 WWID 保持一致cat /etc/udev/rules.d/99-oracle-asm.rules，确认是否存在类似ENV{DM_UUID}=="mpath-3600507680c80833288000000000000ca", SYMLINK+="oracleasm/ora_2"这样的映射规则
如果发现设备名不稳定，不要通过手动修改权限或直接执行 ln -s 来临时处理，而应重新加载规则：udevadm control --reload-rules && udevadm trigger，随后再次验证 /dev/mapper/ora_2 是否能够持续存在。
确认 ASM 实际识别到的磁盘是否与 multipath 设备匹配
即使 multipath -ll 与 udev 检查结果都正常，ASM 仍然可能看不到磁盘。常见原因包括：oracleasm scandisks 没有执行，或者 ASM 的扫描范围配置不正确。
在 grid 用户下执行：
oracleasm scandisks
oracleasm listdisks
如果返回结果为空，或者列出的磁盘名称（如 ORA_DATA01）与 /dev/mapper/ora_2 无法对应，那么问题大概率就出在这一步。常见原因有：
oracleasm configure中的ORACLEASM_SCANORDER没有包含multipath，应设置为"multipath dm"ORACLEASM_SCANEXCLUDE配置错误，误把/dev/mapper/目录排除了- ASM 实例没有启动：可通过
crsctl stat res ora.asm -v | grep STATE检查，确保状态为ONLINE
需要特别注意：所有 ASM 磁盘相关操作，例如 add disk、drop disk，都必须由 grid 用户通过 sqlplus / as sysasm 执行，不能使用 oracle 用户操作。
实际排查 Oracle RAC 多路径存储故障时，最棘手的往往不是某条命令直接报错，而是两个节点之间的状态没有保持一致。比如一侧的 udev 规则已经生效，另一侧却还没有 reload；又或者 iSCSI session 虽然已经登录成功，但遗漏了 iscsiadm -m node --rescan，导致内核设备树没有及时刷新。处理这类问题时，最忌讳的就是零散试错、东查一下西改一下。更稳妥的做法是按照固定步骤逐项检查，并将两个节点上的执行结果逐条对照，这样才能更高效地定位 Oracle RAC 多路径异常的根本原因。
