asmcmd lsdsk无输出说明asm未发现磁盘，属“发现失败”而非“挂载失败”，须用lsdsk -k检查内核路径一致性、比对各节点blkid和权限、验证asm_diskstring配置，排除元数据损坏（ora-15335/ora-15196）后方可继续。
asmcmd lsdsk 无输出？先别碰 SQL*Plus
ASM 磁盘组挂载失败，asmcmd lsdg 看不到磁盘组，大概率不是挂载命令写错，而是 ASM 根本没发现磁盘。这时候直接进 SQL*Plus 执行 ALTER DISKGROUP ... MOUNT 没意义——连磁盘都看不见，挂什么？必须退到操作系统层验证物理可见性：
-
asmcmd lsdsk返回空或报ORA-15033：说明 ASM 扫描不到任何磁盘，属于“发现失败”，不是“挂载失败” -
asmcmd lsdsk -k强制检查内核级设备路径，能暴露节点间路径不一致问题（比如节点1是/dev/mapper/DATA01，节点2是/dev/sdb） - 若
lsdsk有输出但lsdg没有，说明磁盘已识别，但未组成磁盘组，查v$asm_disk.STATE是否为PROVISIONED或FOREIGN
RAC 节点间 lsdsk 输出不一致？这是硬性失败条件
RAC 要求所有节点对同一磁盘的路径、权限、WWID 完全一致。差一个字符，CRS 就无法协调跨节点挂载，alter diskgroup mount 必然静默失败或报 ORA-15063：
- 在每个节点运行：
blkid | grep -i data和ls -l /dev/mapper/ | grep data，逐行比对输出是否完全相同 - 检查
asm_diskstring参数：show parameter asm_diskstring，确保所有节点值一致，且不含重复路径（如同时含/dev/mapper/*和/dev/dm-*） - 若某节点
lsdsk有盘、其他节点没有，优先查该节点的/etc/udev/rules.d/99-asm-disk.rules是否缺失或未生效，执行udevadm trigger --subsystem-match=block
看到 ORA-15335 或 ORA-15196？元数据已损坏，别硬 mount
ORA-15335 几乎等于 ASM 元数据损坏，ORA-15196（如 invalid ASM block header）是磁盘头校验失败的铁证。此时强行 alter diskgroup mount 一定失败，必须跳过 ASM 实例直接抢救：
- 先用
kfod disk=ALL dscv=TRUE查HEADER_STATUS：若为CANDIDATE，说明磁盘头被覆盖 - 用
kfed read /dev/asm-disk1看dsknum、grpname、chksum字段：全为 0 或chksum != computed，确认头块不可信 - 元数据严重损坏时，用
amdu提取文件：amdu -diskstring '/dev/asm*' -extract 'DATA.*' -destination /recovery，注意ORACLE_HOME必须指向 Grid Infrastructure
挂载前必须确认的三件事，漏一项就卡住
不是执行了 CREATE DISKGROUP 或 ALTER DISKGROUP MOUNT 就能成功——底层链路断一环，整个流程就停在 DISMOUNTED 状态：
- 磁盘必须有可读权限：
ls -l /dev/mapper/DATA01显示属主是grid:asmadmin，权限是brw-rw----；不是root:disk或oracle:oinstall - 磁盘不能被其他进程占用：
fuser -v /dev/mapper/DATA01若有输出（如mdadm、lvm），必须清理干净，否则报ORA-15018 - ASM 实例必须处于
MOUNTED状态，且asm_diskstring已正确设置（例如ALTER SYSTEM SET asm_diskstring='/dev/mapper/*' SCOPE=BOTH）
asmcmd lsdsk 在节点 A 正常、节点 B 返回空——这时再翻 alert 日志已经晚了，得立刻切到操作系统层比对设备状态。
