CRS-4639错误表明OHASD进程未启动，需先检查ps -ef | grep ohasd、systemctl status ohas.service及/etc/init.d/init.ohasd权限，再排查ocssd.trc中voting disk不可访问、私网心跳失败或oifcfg配置不一致等问题。
看 crsctl check crs 是否能返回结果
如果执行 crsctl check crs 卡住、无输出，或直接报 CRS-4639: Could not contact Oracle High Availability Services，说明 OHASD 进程根本没起来，问题在最底层。这时候别急着查数据库日志，先确认系统级服务状态：
-
ps -ef | grep ohasd—— 看有没有ohasd进程（注意不是ohas） -
systemctl status ohas.service—— Linux 7+ 上必须检查这个 service 是否 active，常见失败是status=203/EXEC，意味着/etc/init.d/init.ohasd文件权限不对或路径不存在 -
ls -l /etc/init.d/init.ohasd—— 安装后该文件应存在且可执行；若缺失，root.sh可能中途退出过
查 ocssd.trc 里 CRS-1617 和 CRS-1621 错误
这两个错误往往同时出现，指向同一个根因：节点缺少 IPMI 或仲裁配置信息，本质是 Voting Disk 不可用或读取失败。重点盯日志中这三处：
- 是否提示
voting file not accessible或no voting file found - 是否有
IO error on device，尤其关注 ASM diskgroup（如+OCR）是否 mount 成功 - 是否存在
disk HB, but no network HB—— 表示磁盘心跳正常但私网心跳断了，此时ping公网可能通，但私网网卡（如eth2）down 或子网掩码错
验证私网连通性不要只用 ping，得用 telnet rac01 11659（端口见日志里的 interface list），因为 CSSD 走的是 TCP。
比对两节点的 oifcfg getif 和 CLUSTER_INTERCONNECTS
ORA-00126 报错就藏在这里。哪怕集群启动了一半，只要实例尝试注册就会触发校验：
- 在两个节点分别运行
oifcfg getif，确认私网接口名（如eth1）、子网（如192.168.100.0）、类型（cluster_interconnect）完全一致 - 检查每个实例的参数：
show parameter cluster_interconnects，值必须为空（推荐）或与oifcfg输出严格匹配；若手动设过，且和另一节点不同，立刻删掉 - 特别注意：11g 中
CLUSTER_INTERCONNECTS是静态参数，改完要alter system set ... scope=spfile并重启实例，不能热改
留意 crsctl start cluster -n 的节点顺序陷阱
双节点 RAC 启动失败，常因脑裂残留状态导致。比如 rac02 先启失败后，rac01 的 CSSD 仍认为它“活着”，拒绝二次加入：
- 不要同时起两个节点。先强制清理：在任一节点执行
crsctl stop cluster -f，再逐个启动 - 若仍失败，考虑临时停掉所有节点，从单节点冷启：关机 → 启 rac01 → 确认
crsctl check crsOK → 再启 rac02 - 切忌在
crs挂起时执行shutdown abort或 kill -9 进程，容易让 Voting Disk 元数据损坏
真正麻烦的从来不是日志里那行报错，而是多个组件状态不一致时的隐式依赖——比如 OHASD 起不来，CSSD 就不会去读 Voting Disk；CSSD 读不了 Voting Disk，CRSD 就永远等不到仲裁确认。链条上任何一环卡住，整个集群就静默了。
