实例无法启动的主因是ASM磁盘组未挂载，需逐节点用grid用户执行sqlplus / as sysasm查v$asm_diskgroup状态，若为空或全DISMOUNTED则停启库；再用asmcmd lsdsk及lsdsk -k验证磁盘可见性，最后检查udev规则、权限与磁盘头完整性。
实例无法启动，八成不是数据库本身的问题，而是它依赖的 ASM 磁盘组根本没挂上——ORA-01565、ORA-17503、ORA-15001: diskgroup "DATA" does not exist or is not mounted 这类报错，基本就是这个信号。
先查 ASM 实例是否真在运行，别信 crsctl stat res -t
很多人看到 CRS 显示 ora.DATA.dg 是 ONLINE 就以为万事大吉，结果 sqlplus / as sysasm 连进去一查 v$asm_diskgroup 全是 DISMOUNTED，甚至输出为空。RAC 中每个节点的 ASM 实例是独立进程，节点1能 mount，节点2可能早已僵死。
- 必须逐节点切到
grid用户执行：sqlplus / as sysasm→select name, state from v$asm_diskgroup; - 若返回空或全是
DISMOUNTED，立刻停掉所有后续数据库启动动作，先解决 ASM 层 -
crsctl stat res -t只反映资源注册状态，不反映 ASM 实际健康度；ps -ef | grep asm也得看有没有真正 running 的asm_pmon_+ASM进程
asmcmd lsdsk 无输出？说明 ASM 根本没看见磁盘
这是最常被跳过的物理层验证点。不是磁盘坏了，是 ASM 扫描不到设备路径。
- 运行
asmcmd lsdsk：若无输出或报ORA-15033，说明底层设备不可见 - 加
-k参数重试：asmcmd lsdsk -k，它强制走内核设备路径（如/dev/oracleasm/disks/DATA01），能暴露节点间路径不一致问题（比如节点1看到/dev/mapper/DATA01，节点2看到/dev/sdb） - 若
lsdsk -k仍无输出，检查 udev 规则：udevadm trigger --subsystem-match=block+udevadm control --reload-rules，再确认/etc/udev/rules.d/99-asm-disk.rules存在且含正确OWNER="grid"、GROUP="asmadmin"、MODE="0660"
磁盘可见但磁盘组挂不上？重点盯 HEADER_STATUS 和权限
asmcmd lsdsk 有输出、lsdg 却看不到，或挂载时报 ORA-15040: diskgroup is incomplete，说明 ASM 能识别设备，但读不了磁盘头（disk header）。
- 查
v$asm_disk中对应磁盘的HEADER_STATUS：CANDIDATE或PROVISIONED表示头部损坏；FOREIGN可能是跨平台迁移后未执行ALTER DISKGROUP ... IMPORT FOREIGN - 用
kfed read /dev/mapper/DATA01 | grep kfbh.type看磁盘头类型：正常应为FKBTYP_DISKHEAD，若为FKBTYP_INVALID，需用kfed repair恢复（前提是 AU 备份块完好） - 检查设备文件权限：
ls -l /dev/mapper/DATA01必须属grid:asmadmin且权限为0660；RAC 节点间权限必须完全一致，哪怕一个节点是0640，该节点 ASM 就拒绝读取
RAC Data Guard 切换中实例起不来，往往卡在 ASM 层“看不见”或“读不了”这一步；而排查时最容易忽略的是节点间设备路径、权限、udev 规则三者的严格一致性——差一个字符，就全盘失效。
