CRSD反复重启主因是ocssd不稳，需先确认ocssd进程存在且运行时长稳定，再查ocssd.log中CRS-1611/1610、HAIP配置、磁盘心跳及OCR磁盘组状态。
CRSD反复重启不是独立故障，它几乎总是ocssd.bin不稳的连锁反应——先稳住CSSD，CRSD才能真正上线。
确认ocssd进程是否真稳定
别只看ps -ef | grep ocssd有没有输出，重点看运行时长：如果进程刚起来几秒就消失，或crsctl check css返回CRS-4639，说明CSSD根本没站稳。
- 查
/oracle/11.2.0/grid/log/<hostname>/cssd/ocssd.log里是否密集出现CRS-1611或CRS-1610——这是网络心跳丢包的明确信号 - 执行
$GRID_HOME/bin/oifcfg getif -global，输出必须含cluster_interconnect标记；若显示eth1这类旧网卡名，得用oifcfg setif重设并重启集群 -
crsctl query css votedisk返回路径必须可读；asmcmd lsdg中OCR所在磁盘组状态不能是DISMOUNTED
检查crsctl start crs卡在哪一环
命令返回“SUCCESS”不代表CRSD真起来了，它可能卡在ONLINE INTERMEDIATE或秒退到OFFLINE。这不是CRSD代码问题，而是依赖链断了。
-
crsctl stat res -t里ora.cssd必须是ONLINE，否则CRSD连注册都做不到 -
ora.asm要ONLINE且对应ASM实例已mount OCR磁盘组（如+OCRVOTE）；sqlplus / as sysasm连不上，先查asmcmd权限和udev规则 -
ora.storage状态为ONLINE INTERMEDIATE？重点核对各节点/dev/mapper/下OCR设备WWID是否一致——多路径错位会导致ASM挂盘失败
ORA-29740报错别只盯alert.log
ORA-29740是驱逐结果，不是原因。它总伴随evicting instance x from cluster出现在alert_<inst>.log，但根因一定藏在ocssd.log里。
- 搜
IPC Send timeout detected→私网UDP 12345端口被防火墙拦截，或网卡rx_discards非零（ethtool -S ethx | grep disc） - 搜
disk heartbeat failed→voting disk路径不可写、权限不对（应为grid:oinstall，660裸设备），或ASM磁盘组未mount - 搜
Authentication OSD error, op: scls_auth_response_prepare loc: mkdir→/u01/oracle/product/...目录空间满，常见于bdump里几百GB的trace文件
ohasd进程没起来就别硬拉crs
如果crsctl check crs报CRS-4537: Cannot communicate with Cluster Ready Services，说明底层通信断了，优先查ohasd。
-
ps -ef | grep ohasd无输出？先确认/etc/oracle/olr.loc存在且内容正确（如olrconfig_loc=/u01/app/19c/grid/cdata/olr.ocr） - 再执行
sudo /u01/app/19c/grid/bin/crsctl start ohasd，启动后立刻跑crsctl check crs验证 - 别跳步直接
crsctl start crs——ohasd没稳住，CRSD根本不会被触发
最常被忽略的是磁盘权限一致性：OCR/voting盘在所有节点上必须是同一属主（grid）、同一主组（oinstall）、同一权限（660），哪怕差一个bit，CSSD都会拒绝识别。
