oracle rac多路径故障本质是设备映射断裂、权限漂移与asm识别逻辑错位三者叠加，需依次验证multipath -ll输出、强制multipath -v2重建映射、udevadm trigger触发节点生成，并确保ocr.loc路径指向多路径设备而非/dev/sdx。
Oracle RAC存储多路径故障不是“扫不到盘”那么简单，而是设备映射断裂、权限漂移、ASM识别逻辑错位三者叠加的结果。直接重启multipathd或oracleasm大概率无效，甚至引发节点驱逐。
确认多路径设备是否真实重建（multipath -ll输出是否含OCR/VOTE盘）
这是第一道硬门槛。multipathd重启后，/dev/mapper/下设备节点会被销毁，仅靠rescan-scsi-bus.sh无法恢复——它只刷底层/dev/sdX，不触发多路径聚合。
- 执行
multipath -v2强制重建映射（别用-F，会清空所有路径） - 检查输出中是否有你的OCR盘WWID，且状态为
active ready running - 若
/dev/mapper/仍为空，说明multipath.conf里getuid_callout配置错误（例如RHEL6.5用了旧版scsi_id参数） - OCR盘必须出现在所有节点的
multipath -ll输出里；若某节点缺失，crsctl check crs必然卡在CSSD
验证ASM能否真正“看到”这些多路径设备（kfod比SQL*Plus更早暴露问题）
GV$ASM_DISK是缓存视图，可能滞后；kfod模拟ASM启动时的原始扫描逻辑，Header列为CANDIDATE才代表设备可被识别。
- 运行
kfod status=TRUE asm_diskstring='/dev/mapper/*' disk=all - 重点看OCR/VOTE盘对应的
Header列：若为UNKNOWN或空白，说明ASM磁盘头未被读取，不是权限问题，而是设备路径根本没进扫描范围 - 对比两节点输出：若节点1有
/dev/mapper/mpathb，节点2只有/dev/sdb，说明该节点多路径规则未生效或udev未触发 - 别跳过
/proc/partitions：节点2若无对应dm-3条目，内核连块设备都没加载，后续所有操作都是徒劳
检查设备权限与属主是否跨节点严格一致（ls -l /dev/mapper/ocr01）
权限不一致是ORA-15075的头号原因，但chown只是临时补丁——udev规则没固化，下次重扫就回退到root:disk。
- 每个节点执行
ls -l /dev/mapper/ocr01，确认OWNER:GROUP为grid:oinstall（12c+）或grid:asmadmin（11g） - 若用ASMLib，额外检查
ls -l /dev/oracleasm/disks/，链接目标设备的属主必须匹配，且/dev/oracleasm目录本身属主为grid:asmadmin - 查
/etc/udev/rules.d/99-oracle-asm.rules是否含稳定匹配项（如SYSFS{wwid}=="36000c29..."），避免依赖易变的sdX名 - 改完udev规则后必须执行
udevadm control --reload-rules && udevadm trigger --subsystem-match=mpath，否则不生效
OCR磁盘组挂载失败时，先看/etc/oracle/ocr.loc是否指向多路径设备
OCR物理位置由ocr.loc文件硬编码，若它写的是/dev/sdc而实际ASM只认/dev/mapper/mpathc，集群启动必然失败。
- 逐节点检查
/etc/oracle/ocr.loc内容，确保ocrconfig_loc值中的路径是/dev/mapper/xxx或+DG_NAME格式，绝不能是/dev/sdX - 若使用裸设备路径，确认该设备在
multipath -ll中存在且WWID一致；否则OCR将因单点路径中断直接触发I/O hang - 执行
ocrcheck -config验证当前配置是否被CSSD加载；若报Unable to retrieve OCR/OLR status，说明CSSD根本没拿到有效设备路径 - 不要在OCR磁盘组异常时贸然执行
ocrconfig -replace——这需要集群在线，而此时CSSD很可能已崩溃
最易被忽略的是：11gR2+已弃用oracleasm服务，oracleasm scandisks对基于UDEV+multipath的架构完全无效；而19c中OCR磁盘标记为_DROPPED_时，单纯添加新盘不会自动修复，必须先确认旧盘路径是否已在所有节点彻底消失，否则ASM会持续尝试访问已失效路径。
