必须两个节点的 multipath -ll 输出完全一致：设备名、路径数量、每条路径状态均需相同；否则 rac asm 无法识别共享磁盘，导致磁盘组挂载失败或 ocr 丢失。
直接看 multipath -ll 输出是否一致
两个节点的多路径设备列表必须完全对齐，这是最基础也最容易被忽略的一环。常见错误是：一个节点能看到 ora_2、ora_4，另一个节点只看到 ora_2，或者设备名相同但底层路径数不一致（比如一边显示 4 条路径，另一边只有 2 条）。
执行前先确认当前用户有权限：su - root，再运行：
multipath -ll | grep -E "(ora_|size=|status=)"
重点比对三件事：
- 设备名（如
ora_2）在两个节点是否存在且命名一致 - 每个设备下的路径数量是否相同（
-+-下挂的 SCSI 设备行数） - 每条路径的状态是否都是
active ready running，而非failed或ghost
检查 iSCSI 会话是否全部登录成功
iscsiadm -m session 显示的是当前活跃的 iSCSI 连接，不是“配置了就等于连上了”。RAC 环境下每个节点必须通过多个网络接口（通常是两块网卡绑定到不同交换机）分别登录同一 target，否则 multipath 无法形成冗余路径。
典型错误现象：
-
iscsiadm -m session返回空，说明根本没登录 - 只看到 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<br>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 没触发，或扫描范围不对。
在 grid 用户下执行：
oracleasm scandisks<br>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/drop disk）必须在 grid 用户下用 sqlplus / as sysasm 执行，不能用 oracle 用户。
真正容易卡住的地方不是某一步命令失败，而是节点间状态不同步——比如一个节点的 udev 规则生效了，另一个没 reload；或者 iscsi session 登录了但没做 iscsiadm -m node --rescan，导致 kernel 没刷新设备树。排查时别跳步骤，老老实实两边对比着跑一遍。
