INTERMEDIATE是CRS状态机明确阻塞的信号，非“启动中”，而是因OCR/Voting Disk不可写、IPC资源残留或私网通信异常导致状态转换失败。
crsctl stat res -t 显示 INTERMEDIATE 是什么信号
INTERMEDIATE 不是“正在启动中”，而是 CRS 明确卡在状态转换环节，无法完成 ONLINING 或 OFFLINING。它本质是状态机停滞，不是慢，是阻塞。常见于 ora.asm、ora.<db>.db</db>、ora.<dg>.dg</dg> 这类核心资源，也出现在 ora.<vip>.vip</vip> 或自定义脚本资源上。
最常被忽略的三个底层原因
90% 的长期 INTERMEDIATE 状态不来自数据库层，而来自集群栈或操作系统级阻塞：
-
OCR/voting disk不可写：权限不一致（如某节点/dev/mapper/mpathb属主是root:root，另一节点是grid:oinstall）、WWID 不匹配、多路径映射名不统一；运行ocrcheck报PROT-1或CRS-4535即为佐证 - IPC 资源残留：
ipcs -m、ipcs -s、ipcs -q输出中仍有匹配$ORACLE_SID或grid关键字的条目，ocssd.bin或crsd.bin初始化时会拒绝继续 - 私网通信异常：UDP 12345 端口不通、MTU 不一致（如交换机设 9000，主机设 1500）、反向 DNS 解析失败（
nslookup返回 IP 不一致或超时），导致ocssd.log持续报failed to connect to CSS或timeout waiting for node
别信 “进程在就没事” —— 检查 ocspd 和 crsd 存活质量
看到 ps -ef | grep ocssd 有输出不等于服务健康。真正要看的是进程存活时长和日志线索：
- 用
ps -o pid,etime,comm -C ocssd.bin查etime：若小于 60，说明ocssd正在崩溃重启循环，crsctl check cluster -all很可能返回CRS-4537 - 立刻翻
$GRID_HOME/log/<hostname>/cssd/ocssd.log，搜ERROR、timeout、failed to update—— 这比看alert.log有效十倍 -
crsctl check crs若失败，先别动数据库资源，优先执行crsctl start ohasd并确认/etc/oracle/olr.loc存在且可读
强行清理前必须验证的边界条件
直接 ipcrm 或 crsctl delete res 是高风险操作，仅在满足全部条件时才可考虑：
- 确认目标资源确实是本节点独占问题（
crsctl stat res -w "STATE = INTERMEDIATE AND SERVER_NAME = $(hostname)"） - 已检查并排除 OCR 写入失败（
ocrconfig -showbackup可读、ocrdump不报错） - IPC 清理只针对本 SID 或 grid 用户相关条目：
ipcs -a | grep -i "$ORACLE_SID\|grid"，绝不用ipcs -ma - 对
ora.<db>.db</db>类资源，严禁crsctl delete res；应改用srvctl stop database -d <db> -o abort强制终止实例，再等 CRS 自动重试
INTERMEDIATE 状态持续超过 5 分钟，基本可以排除“临时等待”，要立即转向 OCR 权限、私网连通性、IPC 残留这三个硬性检查点 —— 日志里没报错，不等于没出问题。
