先确认ASM实例是否真在运行，再查磁盘是否被看见——90%的“挂载失败”其实卡在前两层，根本没到磁盘组逻辑层面；需用ps -ef | grep asm_pmon验证进程存活，用asmcmd lsdsk -k强制检测设备路径，检查udev规则、权限及AFD接管状态，确保RAC各节点磁盘路径完全一致。
先确认ASM实例是否真在运行，再查磁盘是否被看见——90%的“挂载失败”其实卡在前两层，根本没到磁盘组逻辑层面。
检查本地ASM实例是否存活，别信crsctl stat res -t的假online
CRS资源状态显示ora.DATA.dg为online，不代表ASM实例能干活。节点1的+ASM1可能pmon已僵死，但CRS还没来得及探测到。
- 用
ps -ef | grep asm_pmon看进程是否存在，不是srvctl status asm或crsctl stat res -t - 翻
$ORACLE_HOME/log/hostname/asmalert.log，重点搜ORA-15077（找不到ASM实例）和ORA-15110（没挂任何磁盘组） - 手动启动必须走
srvctl start asm -n nodename，别用sqlplus / as sysasm后startup——后者绕过CRS，后续资源状态会脱节
验证ASM是否真正发现磁盘：lsdsk -k比lsdsk更可靠
asmcmd lsdsk返回空，不等于磁盘坏了，而是ASM根本没扫描到设备路径。尤其RAC中，节点1看到/dev/mapper/DATA01，节点2看到/dev/sdb，就会导致只有一节点能挂。
- 先跑
asmcmd lsdsk；若为空，立刻加-k重试：asmcmd lsdsk -k——它强制走内核设备路径，暴露udev规则或权限不一致 - 若
lsdsk -k仍无输出，检查/etc/udev/rules.d/99-asm-disk.rules是否含OWNER="grid"、GROUP="asmadmin"、MODE="0660" - 改完规则后执行
udevadm trigger --subsystem-match=block和udevadm control --reload-rules，再oracleasm scandisks
磁盘可见但磁盘组挂不上：优先查header_status和AFD接管状态
看到asmcmd lsdsk有输出、lsdg却为空，或报ORA-15040: diskgroup is incomplete，说明磁盘头损坏或AFD没接管。
- 查
v$asm_disk中对应磁盘的HEADER_STATUS：CANDIDATE或PROVISIONED大概率是magic字段（0x6b666564）坏了，不是盘废了 - 用
kfed read /dev/mapper/DATA01 | grep kfbh.type确认头类型；修复必须用kfed repair且显式指定ausz（如AU=4M →ausz=4194304） - 修复后别急着
alter diskgroup mount，先跑asmcmd afd_lsdsk确认状态为a（AFD已接管），否则ASM实例压根看不到它
跨节点路径不一致时，mount操作只在本节点生效
RAC要求所有节点看到的ASM磁盘路径完全一致。节点1用/dev/oracleasm/disks/DATA01，节点2用/dev/mapper/mpathb，即使权限全对，CRS也无法协调状态，结果就是只有发起命令的节点显示MOUNTED，其他节点始终DISMOUNTED。
- 检查
crsctl stat res ora.DATA.dg -p里的PLACEMENT字段，若为空，基本锁定路径不一致 - 统一使用UDEV规则映射，确保所有节点
ls -l /dev/mapper/asm*输出路径、属主、权限完全相同 - 切忌在节点1上
alter diskgroup DATA mount后就认为整个RAC已恢复——必须逐节点验证v$asm_diskgroup.state
最易被跳过的动作是：没确认lsdsk -k输出就直接去修磁盘头；最常被忽略的验证点是：kfed repair后没跑asmcmd afd_lsdsk确认AFD状态。这两步一漏，后面所有操作都是在无效路径上打转。
