ora-15063错误本质是asm实例“视而不见”，需先查v$asm_disk确认磁盘发现状态，再显式配置asm_diskstring、统一udev规则与权限，并确保rac各节点设备路径和属主完全一致。
共享存储路径故障不是“找不到盘”，而是“看到盘但用不了”——根本原因几乎都出在设备路径不一致、权限错位或ASM发现配置失效上。
确认ASM是否真能识别目标磁盘
别跳过这步直接改参数。连到任意ASM实例执行：SELECT path, header_status, mode_status, state FROM v$asm_disk;，重点看三列：
-
path是否指向你预期的设备（如/dev/mapper/datap1），而不是/dev/sdb这种易变路径 -
header_status为MEMBER或PROVISIONED才算被识别；若为FORMER或CANDIDATE，说明磁盘头有残留元数据 - 整行缺失？说明ASM根本没扫到这块盘——问题一定在
asm_diskstring或底层设备权限
检查asm_diskstring是否覆盖所有节点且路径有效
asm_diskstring不是“自动猜路径”的开关，是精确的扫描白名单。RAC中每个ASM实例都需独立生效：
- 查当前值：
SHOW PARAMETER asm_diskstring;，空值或ORCL:*在19c中基本无效 - 避免用
/dev/oracleasm/disks/*（ASMLIB已弃用）或含空格的逗号分隔（如'/dev/mapper/a', '/dev/mapper/b'） - 安全写法是显式列出所有盘，加
SID='*'确保集群同步：ALTER SYSTEM SET asm_diskstring='/dev/mapper/datap1','/dev/mapper/datap2' SCOPE=BOTH SID='*'; - 改完立刻在各节点分别执行
SELECT COUNT(*) FROM v$asm_disk;验证是否返回一致数量
验证多路径设备与权限在所有节点是否完全一致
同一个/dev/mapper/datap1在节点A可读、节点B权限为600，就会导致ASM在B上拒绝挂载：
- 在所有节点运行：
multipath -ll | grep datap，确认输出的WWID、状态（active/enabled）、路径数完全一致 - 检查设备属主：
ls -l /dev/mapper/datap*，必须是grid:asmadmin，且权限为0660 - udev规则必须统一：各节点
/etc/udev/rules.d/99-oracle-asmdevices.rules内容应逐字相同，且重载后执行udevadm control --reload-rules && udevadm trigger - 切忌用
dd if=/dev/zero of=/dev/sdb bs=1M count=100清理磁盘——这会破坏ASM头；要用dd if=/dev/zero of=/dev/mapper/datap1 bs=1M count=100且仅对header_status = FORMER的盘操作
排查OCR/Voting Disk所在磁盘组是否异常
OCR和Voting Disk路径失效会导致整个集群无法启动，但错误日志常被淹没在CSSD日志里：
- 先看
crsctl query css votedisk和ocrcheck -config，确认路径是否指向ASM磁盘组（如+OCR）而非裸设备 - 查
ASMCMD> lsdg，确认OCR磁盘组state为MOUNTED、type为EXTERN或NORMAL，且无_DROPPED_磁盘 - 若OCR磁盘组掉盘，
ASMCMD> lsdsk -kG OCR会显示_DROPPED_条目；此时不能直接删盘，先用cluvfy comp ocr -n all验证集群健康度 - 真正麻烦的是OCR磁盘组本身依赖的底层设备路径在某个节点不可见——这时
v$asm_disk里可能根本看不到OCR盘，得回退到multipath和udev层逐节点比对
最易被忽略的是：同一块物理盘在不同节点映射出的/dev/mapper/xxx名称不同，或者udev规则里用了$kernel这种不稳定变量。这类问题不会报ORA错误，但会让ASM在部分节点静默跳过该盘——必须逐节点比对multipath -ll输出和v$asm_disk.path结果是否严格一致。
