ORA-29702错误导致资源卡在INTERMEDIATE状态，主因是IPC资源残留或OCR/Voting Disk不可写；需先查日志、清理shm/sem/msg，再验证OCR可写性，切忌盲目重启或删除资源。
ORA-29702 错误出现时 crsctl stat res -t 显示资源为 INTERMEDIATE
这是典型的集群资源状态卡住现象，不是“假死”，而是 crs 无法完成状态转换的明确信号。根本原因通常是后台进程（如 ora.asm、ora.cssd 或数据库实例进程）残留了未释放的 ipc 资源或持有锁，导致 ocr/voting disk 操作被阻塞。
实操建议：
- 先确认具体卡住的资源：
crsctl stat res -w "STATE = INTERMEDIATE"，避免盲目重启整个集群 - 检查对应资源的 log：
$GRID_HOME/log/<hostname>/crsd/crsd.log和$ORACLE_HOME/rdbms/log/alert_<inst>.log，搜索ORA-29702或failed to update resource state - 不要直接 kill -9 进程 ——
cssd或ohasd被强杀会导致 Voting Disk 不一致，可能触发脑裂保护
手动清理残留进程前必须验证 IPC 资源是否真正释放
很多 DBA 在看到 ps -ef | grep pmon 没有输出就认为实例已退出，但共享内存段（shm）、信号量（sem）和消息队列（msg）可能还在。这些是 CRS 判断“进程是否干净退出”的关键依据。
实操建议：
- 查共享内存：
ipcs -m | grep $ORACLE_SID，若输出非空，用ipcrm -m <shmid>清理（注意只清本 SID 相关） - 查信号量：
ipcs -s | grep $ORACLE_SID，对应清理命令是ipcrm -s <semid> - 查消息队列：
ipcs -q | grep $ORACLE_SID，清理用ipcrm -Q <msgid> - 执行完后务必再跑一次
ipcs -a确认无残留 —— 否则 CRS 重启资源时仍会失败并回退到INTERMEDIATE
crsctl stop res 失败后改用 crsctl delete res 的风险与边界
当 crsctl stop res ora.db1.db -f 返回 “resource is in INTERMEDIATE state, cannot stop” 时，有人会尝试删资源再重建。这在测试环境可行，但在生产中极易出事。
实操建议：
-
crsctl delete res只删 OCR 中的注册项，不碰磁盘数据 —— 但后续crsctl add res需严格匹配原资源配置（尤其是ACL、PLACEMENT、SCRIPT），错一个参数就会导致启动失败 - 如果资源关联的是 RAC 数据库（
ora.<db>.db），绝对不要删；应优先用srvctl stop database -d <db> -o abort强制终止实例，再等 CRS 自动重置状态 - 只有纯自定义资源（比如用
crsctl add resource手动加的脚本资源）才可考虑删除重建
OCR 写入失败导致状态卡死的快速定位法
INTERMEDIATE 状态持续超过 5 分钟，大概率不是进程问题，而是 OCR 本身不可写。常见于 OCR 磁盘权限变更、ASM diskgroup offline、或 root.sh 重跑后 UID/GID 错乱。
实操建议：
- 运行
ocrcheck -config确认当前 OCR 位置；再用ls -l查该路径所属用户是否为root:oinstall（11g/12c）或grid:oinstall（19c+） - 检查 ASM 磁盘组状态：
asmcmd lsdg，确认 OCR 所在 DG 的state是MOUNTED，且offline_disks为 0 - 临时验证 OCR 可写性：
ocrconfig -manualbackup—— 若报CLSU-00100: Operating System function: ioctl failed with error data: 25，基本锁定是设备权限或 multipath 配置异常
OCR 不可用时，任何资源状态操作都是徒劳。得先让 ocrconfig -showbackup 能返回有效时间戳，再处理 INTERMEDIATE。
