crs-2672卡在ora.cssd启动是因cssd未获ocr/voting disk控制权，需依次检查asmcmd lsdg确认ocr磁盘组mounted、crsctl query css votedisk路径权限与可读性、olsnodes -n验证私网连通性。
crsctl start crs 卡在 ora.cssd 或超时
这不是连接慢，而是 CSSD（集群同步服务）根本没拿到 OCR/voting disk 的控制权。它不依赖数据库，但死卡在存储层——只要磁盘组没 MOUNT、路径不可读、权限不对，或者私网不通，它就永远停在 CRS-2672: Attempting to start 'ora.cssd'。
- 先跑
asmcmd lsdg：看 OCR 所在磁盘组（比如+OCRVOTE）状态是不是MOUNTED；如果是DISMOUNTED，立刻用sqlplus / as sysasm执行ALTER DISKGROUP OCRVOTE MOUNT - 再跑
crsctl query css votedisk：输出的路径（如+OCRVOTE或/dev/mapper/mpathb）必须能在所有节点上被root用户直接ls -l读到，属主是grid:oinstall，裸设备权限必须是660，NFS 文件必须是644 - 查私网连通性：
olsnodes -n必须列出全部节点编号；如果缺一个，去对应节点的$GRID_HOME/log/<hostname>/cssd/ocssd.log</hostname>搜IPC Send timeout或Failed to connect to CSS daemon，八成是防火墙拦了 UDP 12345 端口，或私网网卡 down 了
ora.storage 显示 OFFLINE 或 HANG 住
这个资源不启动，后续所有数据库实例、监听器、VIP 都起不来。日志里常见 ORA-12541: TNS:no listener 或 CRS-5055: unable to connect to an ASM instance，本质不是监听器问题，而是 ASM 实例压根没起来，或者起了但挂不了盘。
- 别急着
srvctl start asm：先确认 ASM 进程是否真在运行——ps -ef | grep pmon | grep +ASM，没输出说明 ASM 没启；有输出但asmcmd lsdg报错，说明磁盘组不可见 - 检查多路径一致性：在每个节点执行
ls -l /dev/mapper/*或ls -l /dev/asm*，OCR/voting 盘的 WWID 必须完全一致；ASMLIB 用户还要核对oracleasm listdisks输出和crsctl query css votedisk路径是否匹配 - 注意 grid 用户环境变量：
ORACLE_HOME末尾多一个/（比如/u01/app/19.0.0/grid/）会导致crsctl start res ora.asm静默失败，echo $ORACLE_HOME看一眼最省事
crsctl check crs 报 CRS-4537
这不是 CRS 启动失败，是整个高可用框架（OHAS）根本没加载。所有 crsctl 命令都依赖本地 ohasd 进程通信，它挂了，命令就全废。
- 立刻执行
ps -ef | grep ohasd：没输出就别碰crsctl start crs，先救底层 - 检查
/etc/oracle/olr.loc：内容应类似olrconfig_loc=/u01/app/19c/grid/cdata/olr.ocr，路径必须存在且可读；文件权限要是644，不能是600（否则ohasd启动静默失败） - 手动拉起：
sudo /u01/app/19c/grid/bin/crsctl start ohasd，之后马上跑crsctl check crs，看到CRS-4638: Oracle High Availability Services is online才算真正恢复通信能力
crsctl stop crs 失败并提示 CRS-2501
这说明 CRS 栈已经严重损坏——CSSD 进程崩溃后没清理注册信息，OCR 里还存着旧状态。硬等或反复重试只会让资源进入 UNKNOWN 状态，更难诊断。
- 别执行
crsctl start crs -f强制覆盖：可能把 OCR 写坏 - 先停干净：
crsctl stop crs -f后，用ps -ef | grep -i 'ora_|crs_|ohasd'确保输出为空；若有残留进程，kill -9掉 - 安全清理本地缓存：
mv $GRID_HOME/cdata/<cluster_name>/backup* /tmp/</cluster_name>（仅限单节点操作，且确认该节点已离线）；之后再走正常crsctl start ohasd→crsctl start crs流程
真正卡住的地方，往往不在日志第一行报错，而在 OCR 设备读取延迟、SSH 超时、或 home 目录权限这种“看起来无关”的细节上。修之前，先测 dd if=/dev/oracle/ocr01 of=/dev/null bs=4k count=100 iflag=direct 和 ssh -o StrictHostKeyChecking=no -o ConnectTimeout=5 oracle@rac2 date —— 这两件事比翻一百行日志更快定位根因。
