答案是：90%的“无法挂载”实为asm未发现磁盘，应先用asmcmd lsdsk验证物理可见性；若无输出，需加-k参数检查内核路径一致性，并排查udev规则、权限及节点间设备状态是否完全一致。
先别急着修磁盘组，90% 的“无法挂载”根本不是磁盘组坏了，而是 ASM 连磁盘都没看见。
asmcmd lsdsk 无输出？说明 ASM 根本没发现磁盘
看到 ORA-15033: diskgroup 'DATA' is not mounted 或 lsdg 列表为空，第一反应不该是“头坏了”，而是验证物理层是否可见。
- 运行
asmcmd lsdsk：若返回空或报错，证明 ASM 扫描不到任何设备 —— 这是发现失败，不是挂载失败 - 加
-k参数重试：asmcmd lsdsk -k，它绕过 ASM 缓存，强制读内核设备路径，能暴露节点间路径不一致（比如节点1是/dev/mapper/DATA01，节点2是/dev/sdb） - 若仍无输出，检查 udev 规则是否生效：
udevadm trigger --subsystem-match=block+udevadm control --reload-rules，再确认/etc/udev/rules.d/99-asm-disk.rules中OWNER="grid"、GROUP="asmadmin"、MODE="0660"是否正确
kfed read 报 KFED-00322？磁盘头 magic 损坏，但大概率能救
KFED-00322: Invalid ASM disk header block magic number 只表示 LBA 0 头块前 4 字节（0x6b666564）被破坏，只要没被 dd 清零、没被 multipath 覆盖、ASM 实例也没在运行中反复扫描，备份头（如 AU=4M 时位于 blkn=2046）通常完好。
- 必须用
root用户执行：kfed repair /dev/mapper/DATA01 ausz=4194304（AU=4M），ausz填错直接导致后续挂载失败 - 修复后立即验证：
kfed read /dev/mapper/DATA01 | egrep 'kfbh.type|dsknum|grpname'，确认kfbh.type是KFBTYP_DISKHEAD，且dsknum、grpname与原盘一致 - 修复完别急着
ALTER DISKGROUP MOUNT，先跑asmcmd afd_lsdsk确认状态为a（AFD 已接管），否则 ASM 实例根本看不到这块盘
v$asm_disk 中 HEADER_STATUS=CANDIDATE？别删盘，先查备份头
看到 HEADER_STATUS=CANDIDATE 就执行 ALTER DISKGROUP DROP DISK 是最常见误操作 —— 这通常是 magic 损坏的假象，不是真成了新盘。
- 用
kfed read /dev/mapper/DATA01 blkn=2046（AU=4M 场景）读备份块：若返回非全零且含有效dsknum、grpname，说明可repair；若全零或乱码，才考虑merge（风险极高，需同版本/同 AU/同冗余的模板头） -
kfed merge必须带chksm=yes，漏掉会导致 checksum 校验失败，ASM 拒绝识别 - 查
v$asm_disk时注意 RAC 各节点状态独立：节点1显示MEMBER，节点2可能是CANDIDATE，必须逐节点检查
挂载后 RMAN RESTORE 仍失败？路径和 SWITCH 没做对
即使磁盘组已 MOUNTED，RMAN 也可能卡在 RESTORE DATAFILE 并报 ORA-15012 或 ORA-01157 —— 因为控制文件里记录的文件路径（如 /u01/oradata/orcl/users01.dbf）和 ASM 中实际位置（如 +DATA/orcl/datafile/users.256.123456789）不一致。
- RMAN 中必须先
SET NEWNAME FOR DATAFILE 4 TO '+DATA'（不是完整 ASM 文件名），再RESTORE TABLESPACE users - 还原完成后必须执行
SWITCH DATAFILE ALL，否则RECOVER阶段会因路径不匹配直接失败 - 如果归档日志也存在坏盘上，
RECOVER会卡在第一个缺失归档，报ORA-00308—— 需人工从备份集中提取最小 SCN，确认归档链完整性
真正卡住人的地方，往往不是 SQL 写错，而是节点 A 的 asmcmd lsdsk 有输出、节点 B 返回空，或者 kfed repair 后忘了 asmcmd afd_lsdsk 验证 AFD 状态 —— 这些细节不查，后面所有操作都是徒劳。
