ORA-15032与ORA-15075组合错误表明ASM在RAC某节点无法识别指定磁盘路径，主因是权限或设备可见性不一致，需同步检查属主、多路径配置及ASM磁盘发现状态。
ORA-15032 + ORA-15075：磁盘在RAC节点间不可见的典型表现
这个组合错误本质不是语法或命令写错，而是asm实例在某个（或多个）rac节点上根本“看不见”你指定的磁盘路径。常见现象是：alter diskgroup data add disk '/dev/mapper/backup1p1' 在节点1成功，节点2报 ora-15075: disk(s) are not visible cluster-wide，紧接着触发 ora-15032: not all alterations performed。
根本原因几乎总是权限或设备可见性不一致。比如：
- 节点1上
/dev/mapper/backup1p1属主是grid:oinstall，节点2上还是root:root - 多路径设备未在所有节点完成
udev规则加载，导致节点2看到的是原始/dev/sdb而非统一别名 - 使用了NFS挂载点（如
/mnt/nfs/disk1）——ASM根本不支持NFS作为磁盘路径，无论权限怎么调都会失败
必须检查的三处操作系统级状态
别急着进SQL*Plus，先在每个RAC节点上同步确认以下三项：
- 运行
ls -l /dev/mapper/backup1p1（或你的目标路径），确保属主属组统一为grid:oinstall（Oracle 11g/12c默认）或oracle:asmadmin（部分19c部署），且权限是brw-rw---- - 执行
ls -l /dev/oracleasm/disks/（如果用了ASMLib），确认磁盘链接指向正确物理设备，且该目录本身属主是oracle:dba或grid:asmadmin - 查
cat /proc/partitions | grep -i backup和multipath -ll | grep -A5 backup，验证设备是否真实存在、是否被多路径识别、WWID是否一致
权限改完仍失效？警惕udev和ASMLib的自动覆盖
有些Linux发行版（尤其是SLES/SUSE）的 udev 服务会在设备重扫后强制恢复默认权限。手动 chown grid:oinstall /dev/mapper/backup1p1 可能只生效几分钟，随后又变回 root:disk。
真正可靠的方案是固化规则：
- 在所有节点创建
/etc/udev/rules.d/99-asm-disk.rules，内容如：KERNEL=="mapper/backup1p1", OWNER="grid", GROUP="oinstall", MODE="0660" - 运行
udevadm control --reload-rules && udevadm trigger --subsystem-match=block - 若用ASMLib，务必在每台节点执行
/etc/init.d/oracleasm configure并确认提示中选了“y”启用自启动和权限设置
验证磁盘是否真被ASM发现，而不是靠猜
别只信 ls -l，要让ASM自己说话。以 grid 用户登录后执行：
-
sqlplus / as sysasm—— 注意必须是sysasm，sysdba会直接报ORA-15260 - 查
SELECT path, header_status, mode_status FROM v$asm_disk WHERE path LIKE '%backup%';，如果返回空或header_status = 'UNKNOWN'，说明ASM压根没扫描到该设备 - 跨节点对比
SELECT inst_id, path FROM gv$asm_disk WHERE path LIKE '%backup%';，找出哪个inst_id缺失记录，就去对应节点重点排查
最常被忽略的一点：磁盘路径在所有节点必须**完全一致**。哪怕只是节点2多了一个软链接层级（比如 /dev/backup1p1 → /dev/mapper/backup1p1），ASM也可能拒绝识别。路径字符串必须一字不差。
