crsctl check cluster 报 CRS-4537 或超时，说明本地节点 crsd 未启动或与 ohasd 通信中断；需先检查 ohasd 进程及 systemd 状态，再查 olr.loc、OCR 权限、SELinux 等诱因。
crsctl check cluster 报 CRS-4537 或直接超时，说明什么
这通常不是“集群挂了”，而是本地节点的 crsd 进程没起来，或与 ohasd 通信中断。重点先看 ohasd 是否在运行：ps -ef | grep ohasd；如果没进程，crsctl check cluster 必然失败——它依赖 ohasd 提供的本地代理服务，不直连远程节点。
常见诱因包括：/etc/oracle/olr.loc 路径错误、磁盘权限异常（尤其 OCR 设备）、SELinux 强制拦截 socket 绑定。别急着 reboot，先用 systemctl status ohasd 看 systemd 单元状态，再查 /var/log/oracle/crsd/crsd.log 最近 20 行。
crsctl stat res -t 显示资源 OFFLINE 但状态为 INTERMEDIATE
INTERMEDIATE 是 Oracle Clusterware 的中间态，意味着资源启动流程卡在某个检查点，比如依赖的网络 VIP 没就绪、ASM 实例未 mount OCR 所在磁盘组、或自定义脚本 start 方法返回非零退出码但没抛出明确错误。
- 用
crsctl stat res <resource_name> -p查看完整配置，重点关注START_DEPENDENCIES和STOP_DEPENDENCIES - 用
crsctl stat res <resource_name> -init查初始化阶段日志路径，去对应$ORACLE_HOME/log/<node>/agent/crsd/<agent_name>/<resource_name>.log找真实失败原因 - 避免手动
crsctl start res强启——若依赖关系未满足，会反复退回到INTERMEDIATE
crsctl stop crs 不生效，or CRS-2501 提示资源正在使用中
crsctl stop crs 实际是停本节点所有 Clusterware 进程（crsd、cssd、evmd），但它要求所有资源已 clean shutdown。若某数据库实例没正常关闭，或 SCAN Listener 卡在 close 阶段，就会阻塞整个停止流程。
此时不要 kill -9 进程。正确做法是：
- 先用
crsctl stat res -w "STATE == 'ONLINE'"筛出仍在 ONLINE 的资源 - 对数据库资源，优先尝试
srvctl stop database -d <db_name>；对 listener，用srvctl stop listener - 若仍卡住，检查
crsctl stat res -t中该资源的ENABLED状态是否为DISABLED——若是，说明之前被人工 disable 过，需先crsctl enable res <name>再 stop
ohasd.bin 启动失败，日志里反复出现 CLSU-00100 和 ORA-00600
ohasd 是整个 Clusterware 的根进程，它启动失败意味着底层支撑缺失。其中 CLSU-00100 多半指向 OCR 设备不可读（如 ASM diskgroup 未加载、裸设备权限不对），而嵌套的 ORA-00600 往往是 OCR 文件头校验失败或版本不匹配（比如用 19c 的 ocrconfig 工具误操作了 12.1 的 OCR）。
关键动作顺序不能错：
- 确认
/etc/oracle/olr.loc中olrconfig_file=指向的文件存在且可读（ls -l+file命令验证） - 运行
ocrcheck -config看当前 OCR 配置是否合法；若报错，用ocrconfig -showbackup找最近可用备份，再ocrconfig -restore - 切勿在 ohasd 启动失败时运行
crsctl start crs——它会静默跳过 ohasd，导致后续所有命令都失效
OCR 和 OLR 的一致性比你想象中更脆弱；一次磁盘重映射或 udev 规则变更，就可能让 ohasd 在读取 olr.loc 后无法定位 OCR 设备。这种问题往往不报具体路径，只打一堆内部错误码。
