asmcmd lsdsk无输出说明ASM未发现磁盘，属发现失败而非磁盘损坏；需用lsdsk -k验证内核路径一致性，检查udev规则、asm_diskstring配置及节点间设备权限和路径是否完全一致。
asmcmd lsdsk 无输出，说明 ASM 根本没看见磁盘
这不是磁盘坏了，而是 ASM 连设备文件都没扫描到。所有后续操作（比如 ALTER DISKGROUP MOUNT）都无效，必须先解决发现层问题。
- 运行
asmcmd lsdsk：若返回空或报ORA-15033: diskgroup 'DATA' is not mounted，说明 ASM 扫描失败，不是挂载失败 - 加
-k参数重试：asmcmd lsdsk -k，它绕过 udev 缓存，直接读内核设备路径，能暴露节点间路径不一致（如节点1是/dev/mapper/DATA01，节点2是/dev/sdb） - 若仍无输出，检查 udev 规则是否生效：
udevadm trigger --subsystem-match=block+udevadm control --reload-rules，再确认/etc/udev/rules.d/99-oracle-asm.rules存在且含正确 WWID 和OWNER="grid"、GROUP="asmadmin"、MODE="0660"
asm_diskstring 配错导致磁盘“存在却不可见”
ASM 不会自动猜路径，asm_diskstring 是唯一扫描入口。默认为 NULL 在 19c+ 中基本失效，必须显式设置。
- 查当前值：
SHOW PARAMETER asm_diskstring；常见错误值包括ORCL:*（ASMLib 已弃用）、/dev/oracleasm/disks/*（仅限旧 ASMLib 环境） - RAC 必须逐节点确认一致：节点 A 能看到
/dev/mapper/datap1，节点 B 却配置了/dev/dm-12，CRS 就会拒绝协调挂载 - 安全写法是明确列出路径：
ALTER SYSTEM SET asm_diskstring='/dev/mapper/datap1','/dev/mapper/datap2' SCOPE=BOTH SID='*';（SID='*'表示对所有 ASM 实例生效）
v$asm_disk 里有盘但 header_status 不对
磁盘被发现，但 ASM 无法读取头部，就进不了磁盘组。此时 lsdg 可能显示 DISMOUNTED 或干脆不出现。
-
SELECT path, header_status, state FROM v$asm_disk;—— 关键看header_status：MEMBER正常，PROVISIONED表示未加入磁盘组，FORMER或CANDIDATE说明有残留元数据 - 用
kfed read /dev/mapper/DATA01 | grep kfbh.type检查磁盘头类型：正常应为FKBTYP_DISKHEAD，若为FKBTYP_INVALID，需kfed repair（前提是有 AU 备份块） - 扩展分区不能直用：
fdisk -l查/dev/sda1若是Type=5 Extended，ASM 会静默跳过——必须用主分区或逻辑分区
权限和设备路径在 RAC 节点间不一致
RAC 挂载失败的真正卡点，往往藏在节点间微小差异里：一个字符不同，CRS 就拒绝启动。
- 每个节点执行：
blkid | grep -i data和ls -l /dev/mapper/ | grep data，逐行比对 WWID、路径、属主、权限是否完全相同 - 检查
ls -l /dev/mapper/DATA01：必须是brw-rw---- 1 grid asmadmin，不是root:disk或oracle:oinstall（12c+ 默认要求asmadmin组） - 多路径别名冲突：若
asm_diskstring同时含/dev/mapper/DATA01和/dev/dm-12，会触发ORA-15077+ORA-15063，ASM 直接拒载
真实场景里最耗时间的，不是命令敲错，而是节点 A 的 asmcmd lsdsk 有输出、节点 B 返回空——这时再翻 alert.log 已经晚了，得立刻切到操作系统层比对设备状态。
