ASM实例崩溃即集群失能起点，因CRS依赖其加载OCR/Voting Disk等关键资源，ASM未运行则数据库无法mount、集群无法启动。
ASM实例崩溃 ≠ 仅丢存储服务，而是集群“失能”起点
Oracle 19c RAC中，ASM实例不是可选组件，它是集群资源协调的底层依赖。一旦ora.asm进程异常终止，CRS无法加载磁盘组元数据，后续所有资源（包括OCR、Voting Disk、数据库实例）启动全部阻塞。你看到的“集群宕机”，本质是CRS在初始化阶段就卡死，报错如CRS-4530: Communications failure contacting Cluster Synchronization Services daemon或ORA-15063: ASM discovered an insufficient number of disks——这不是服务挂了，是整个集群连“心跳”都发不出去。
OCR和Voting Disk读取失败是直接导火索
ASM实例崩溃后，ora.crsd进程尝试读取OCR磁盘组（如+CRS）时会失败，因为OCR必须通过ASM路径访问；同样，CSSD进程依赖Voting Disk做节点仲裁，而Voting Disk也通常放在ASM磁盘组里。这两类关键设备一旦不可读，集群立刻进入“分裂脑”防护状态：
- OCR不可读 →
crsctl start crs卡在ora.crsd启动，ocrcheck报PROT-602或直接超时 - Voting Disk不可达 →
crsctl query css votedisk返回空或ERROR: no voting files found，节点无法完成加入集群流程 - 两者同时失效 → 所有节点反复尝试重连、超时、退出，
crsctl check cluster -all全红，业务数据库自然离线
别指望数据库实例还能“单干”
有人以为只要数据库实例没崩，还能手动连上去查点数据——这是严重误判。19c中，数据库实例启动强依赖ASM提供的磁盘组信息：
-
startup mount阶段需从ASM读取控制文件，而控制文件路径（如+DATA/orcl/control01.ctl）必须经ASM解析为物理块地址 - 若ASM未运行，
ALTER SYSTEM SET asm_diskstring等参数无效，v$asm_disk为空，SELECT * FROM v$asm_diskgroup直接报ORA-15032 - 即使控制文件在本地文件系统，归档日志、数据文件、临时表空间等几乎全部落在ASM中，缺失ASM即等于缺失90%以上IO路径
恢复顺序不能颠倒：先稳ASM，再动OCR和DB
遇到ASM崩溃，切忌直接重启数据库或盲目crsctl start crs。真实恢复链路是单向且脆弱的：
- 确认ASM是否真崩溃：
ps -ef | grep pmon | grep +ASM，若无输出，再查grid用户下tail -20 $ORACLE_HOME/log/$(hostname)/asm/alert*.log - 检查磁盘可见性：
asmcmd lsdsk为空？先查ls -l /dev/mapper/asm*权限、scsi_id -g -u -d /dev/sdX输出是否跨节点一致 - 排除ASMLib干扰：若
lsmod | grep oracleasm有输出，必须先rmmod oracleasm并清udev规则，否则ASMFD根本起不来 - ASM起来后，立刻验证OCR：
ocrcheck -config看路径，ocrconfig -showbackup确认备份可用——此时才具备后续恢复基础
最易被忽略的一点：ASM实例能启动，不等于OCR磁盘组已MOUNT。常见情况是ASM起来了，但sqlplus / as sysasm里SELECT state, name FROM v$asm_diskgroup显示+CRS为DISMOUNTED。这时候得人工ALTER DISKGROUP CRS MOUNT，否则OCR仍不可用——而这个动作，必须在所有节点ASM都正常、且磁盘头干净的前提下才能成功。
