ORA-15042错误本质是ASM实例未发现目标磁盘，主因是asm_diskstring配置错误、grid用户权限不足或磁盘头损坏；需先查v$asm_disk确认识别状态，再依次修正参数、权限及磁盘头。
ORA-15042 之类报错，基本等于 ASM 实例“没看见”那块盘——不是磁盘坏了，而是发现、权限或磁盘头三者之一出了问题。
查 v$asm_disk 确认 ASM 是否真识别到磁盘
别急着重启或删磁盘组，先连上 ASM 实例（sqlplus / as sysasm）执行：
SELECT path, header_status, mode_status, state FROM v$asm_disk;
重点看三列：
-
path是否包含你期望的设备路径（如/dev/mapper/datap1） -
header_status是否为MEMBER或PROVISIONED；若为CANDIDATE或FORMER，说明磁盘头残留或损坏 -
state是否为NORMAL；若某盘完全没出现在结果里，说明它根本没被发现
常见现象：v$asm_disk 返回空或只显示部分磁盘 → asm_diskstring 配置错误或底层权限未到位。
检查并重设 asm_diskstring 参数
asm_diskstring 不是“自动猜路径”，19c 默认为 NULL，但实际常因 udev/multipath 规则失效。必须显式指定且 RAC 中每个节点都要生效：
- 查当前值：
SHOW PARAMETER asm_diskstring - 错误写法：
'ORCL:*'（ASMLIB 已弃用）、'/dev/oracleasm/disks/*'（仅旧 ASMLIB 有效） - 安全写法：逗号分隔、无空格、指向真实设备路径，例如：
'/dev/mapper/datap1','/dev/mapper/datap2','/dev/mapper/frap1' - 生效命令（RAC 必须加
SID='*'）：ALTER SYSTEM SET asm_diskstring='/dev/mapper/datap1','/dev/mapper/datap2' SCOPE=BOTH SID='*';
改完立刻查 v$asm_disk，若盘仍不出现，问题不在参数，而在下一层。
验证磁盘权限与磁盘头状态
即使 asm_diskstring 正确，grid 用户也必须对设备有读写权限，且磁盘头不能损坏：
- 确认设备属主和权限：
ls -l /dev/mapper/datap1应为grid:asmadmin且至少brw-rw---- - 若
header_status = CANDIDATE，极可能是磁盘头被覆盖（比如有人在上面建了 LVM 或分区），需用kfed恢复 - 先备份（关键！）：
kfed read /dev/mapper/datap1 blkn=2046 > datap1.diskhead.bak（AU=4M 时备份块在 2046） - 修复命令：
kfed repair /dev/mapper/datap1 aus=4194304（aus必须与原磁盘 AU 大小一致，否则失败）
修复后再次查 v$asm_disk，header_status 应变为 PROVISIONED 或 MEMBER，再尝试 ALTER DISKGROUP ... MOUNT。
磁盘物理层不可见时的排查顺序
如果 v$asm_disk 完全为空，说明 ASM 连设备都看不到，此时要跳过数据库层，直查系统：
- 在所有 RAC 节点运行：
lsblk和multipath -ll，确认共享存储是否被识别 - 检查 udev 规则是否一致（
/etc/udev/rules.d/99-oracle-asm.rules），尤其 WWID 是否匹配 - 查系统日志：
journalctl -u multipathd | grep -i "fail\|error"，看是否有路径 down 或 IO timeout - 确认心跳超时设置：
lsattr -E -a rw_timeout -F value -l hdiskX（AIX）或对应 Linux 多路径 timeout 值，ASM 心跳间隔必须大于该值
真正棘手的从来不是 SQL 命令输错，而是某台节点的 udev 规则漏了一行，或者某块盘的 rw_timeout 比 ASM 心跳还短——这类问题不会报 ORA 错误，只会让磁盘静默掉线。
