CRS-1607 表示节点被正式驱逐，本质是 ora.cssd 因 OCR 或 voting disk 不可达而反复重启或卡在 INIT 状态，需先验证底层存储路径、权限、ASM 挂载状态及私网连通性。
CRS-1607 错误不是进程“挂起”，而是 ora.cssd 进程因 OCR 或 voting disk 不可达而反复重启或卡在 INIT 状态，本质是集群心跳中断。直接杀进程或重启 CRS 没用，必须先确认底层存储路径和权限是否真实就绪。
检查 OCR/voting disk 是否真正 MOUNTED 且可读
很多人只看 crsctl query css votedisk 输出路径，却没验证该路径在当前节点是否能被 root/grid 实际访问：
- 运行
asmcmd lsdg，确认 OCR 所在磁盘组（如OCRVOTE）状态为MOUNTED，且Usable_file_mb > 0 - 若显示
DISMOUNTED，需用sqlplus / as sysasm手动执行ALTER DISKGROUP OCRVOTE MOUNT - 用 root 用户执行
ls -l $(crsctl query css votedisk | grep "^\s*[0-9]" | awk '{print $NF}')，确认输出路径存在、属主为grid:oinstall、权限为660（裸设备）或644（NFS 文件） - 若路径是 ASM 别名（如
+OCRVOTE），还需验证asmcmd ls +OCRVOTE能列出内容，否则说明 ASM 实例未真正挂载该组
验证私网连通性与 CSSD 日志中的 IPC 异常
ora.cssd 启动失败的第二大原因是私网不通，但错误不会直接报在网络层——它会静默卡在 IPC 初始化阶段：
- 执行
olsnodes -n，若某节点缺失，立即查$GRID_HOME/log/<hostname>/cssd/ocssd.log</hostname> - 重点搜索关键词：
IPC Send timeout、Failed to connect to CSS daemon、clsc_connect: (ADDRESS=(PROTOCOL=ipc) - 用
ping -c 5 -s 8972 <private_ip></private_ip>测试巨型帧（MTU=9000）连通性；失败则临时改回 MTU=1500 并检查云平台安全组或物理交换机 ACL - 确认私网接口已关闭
arp_ignore和arp_announce：sysctl net.ipv4.conf.<ifname>.arp_ignore</ifname>应为1，arp_announce应为2
确认 ohasd 是否存活且 olr.loc 配置有效
CRS-1607 常伴随 crsctl check crs 报 CRS-4537，这说明整个高可用框架根本没起来，ora.cssd 还没机会启动：
- 立刻执行
ps -ef | grep ohasd，若无输出，说明ohasd进程未运行 - 检查
/etc/oracle/olr.loc是否存在、路径可读：cat /etc/oracle/olr.loc应输出类似olrconfig_loc=/u01/app/19c/grid/cdata/olr.ocr，且该路径下有文件且属主为root:root - 若
olr.ocr文件缺失或损坏，需从备份恢复（不能重跑root.sh）；若权限不对（如600），改为644 - 手动启动：
sudo /u01/app/19c/grid/bin/crsctl start ohasd，之后必须等 30 秒再执行crsctl check crs，看到CRS-4638才算真正恢复
最容易被跳过的是多路径设备映射一致性——OCR 所在 LUN 在 node1 上识别为 /dev/mapper/mpathb，在 node2 上却是 /dev/mapper/mpathc，会导致 ora.cssd 在一个节点能读、另一个节点读失败。别只信 crsctl query css votedisk 的输出，每个节点都得单独验证设备路径和权限。
