ORA-15032是汇总错误，真正原因需看后续ORA-xxxx错误；应优先查GV$ASM_DISK定位节点级磁盘识别问题，核验设备权限、多路径一致性、ASM_DISKSTRING参数及磁盘头状态。
ora-15032 几乎从不单独出现，它只是个“汇总错误”——真正的问题藏在紧随其后的那个 ora-xxxx 错误里。 比如 ora-15075（磁盘集群不可见）、ora-15071（磁盘正被删除）、ora-15410（failgroup 大小不一致）等。直接调权限或重启 asm 实例，大概率白忙。
查 GV$ASM_DISK 确认哪些磁盘“没被看到”
别只看单节点的 v$asm_disk，RAC 下必须用全局视图定位问题磁盘：
- 运行
SELECT inst_id, group_number, disk_number, mount_status, header_status, path FROM gv$asm_disk WHERE path LIKE '%backup1p1%' OR path LIKE '%asm-diskh%'; - 重点看
inst_id列：如果某磁盘在节点 2 的记录是空的，或header_status是PROVISIONED/UNKNOWN，说明该节点根本没识别到设备 - 若
mount_status是CLOSED且header_status是FORMER，说明磁盘头已被清空，但 ASM 还没刷新缓存（需ALTER DISKGROUP ... DISMOUNT/MOUNT或重启 ASM）
验证 /dev 下设备权限与属主是否跨节点一致
ORA-15075 最常见原因就是权限不统一。不是“改了就行”，而是“所有节点上必须完全一致”：
- 在每个 RAC 节点执行：
ls -l /dev/mapper/backup1p1和ls -l /dev/asm-diskh，确认OWNER:GROUP均为grid:oinstall（12c 默认），权限为brw-rw---- - 若用 ASMLib，额外检查：
ls -l /dev/oracleasm/disks/，确保链接目标设备属主正确，且该目录本身属主是grid:asmadmin - 注意：手动
chown只是临时修复。udev 规则未固化时，下次多路径重扫或系统重启后会还原为root:disk
用 kfod 和 multipath 工具交叉验证设备可见性
操作系统级工具比 SQL*Plus 更早暴露问题，绕过 ASM 缓存干扰：
- 运行
kfod status=TRUE asm_diskstring='/dev/mapper/*' disk=all—— 它模拟 ASM 启动时的发现逻辑，输出中Header列为CANDIDATE才算真正“可被识别” - 执行
multipath -ll | grep -A5 backup，确认 WWID 在所有节点一致；若节点 2 显示的是sdb而非mapper/backup1p1，说明多路径未生效 - 检查
/proc/partitions：节点 2 若无对应设备名（如dm-3），说明内核根本没加载该块设备，此时权限再对也无效
警惕隐藏参数和磁盘头状态引发的假性失败
有些 ORA-15032 是 ASM 主动拒绝，而非设备不可见：
- ORA-15410/ORA-15411：添加大小不一致的磁盘到同一 failgroup，需临时启用
_asm_disable_failgroup_size_checking=TRUE（仅限测试环境） - ORA-15201：
kfod显示磁盘是CANDIDATE，但dd if=/dev/zero of=/dev/asm-disk6 bs=8192 count=2560仍失败？先用kfed read /dev/asm-disk6看磁盘头是否残留旧 ASM 签名（kfbh.type非 0） - ORA-15036：
kfed read中ausize或dsksz字段与实际设备大小不符，必须用kfed write修正，否则 mount 必报错
最易被忽略的一点：ASM_DISKSTRING 参数值在各节点是否一致？哪怕只差一个通配符（如 /dev/mapper/* vs /dev/mapper/backup*），也会导致部分磁盘被过滤掉——而这个参数不会报错，只会静默跳过。
