ora-29701本质是ohas/css未就绪，需先验证ohasd进程、/var/tmp/.oracle/socket文件及olr有效性，再排查私网、ipc、selinux、/dev/shm和udump空间，而非重启实例或修改数据库参数。
ora-29701 不是数据库层配置问题，而是底层集群同步服务（css）或高可用服务（ohas）根本未就绪——在 12c rac 中，直接运行 crsctl start crs 或反复重启实例毫无意义，必须先确认并修复 ohas/css 的存活状态。
检查 ohasd 进程是否真实运行
别信 crsctl check has 的返回值，它可能因 IPC 通信中断而假阳性。真正可靠的判断方式是：
- 执行
ps -ef | grep ohasd，确认有 root 用户启动的/u01/app/12.1.0/grid/bin/ohasd进程（注意路径中的版本号） - 检查
/var/tmp/.oracle/下是否存在socket文件，以及OCSSD_LL_<hostname>_crs</hostname>类型的 socket 是否可访问（ls -l /var/tmp/.oracle/OCSSD*） - 若进程不存在，或 socket 文件为空、属主异常（非 root:root），说明 OHAS 初始化失败，不能跳过这步直接查 OCR
验证 OLR（Oracle Local Registry）是否有效
12c RAC 启动依赖 OLR 而非 OCR 来定位本地集群元数据。常见失效点：
-
/etc/oracle/olr.loc文件缺失、权限不是 644、内容指向的设备不可读（如olrconfig_loc=+OCR_VOTE但 ASM 实例未起来） - OLR 所在磁盘组离线，或
ocrcheck -local报错 “PROT-22: Failed to retrieve data from the local registry” - 手动重建前，务必先停掉所有残留：用
/u01/app/12.1.0/grid/crs/install/rootcrs.pl -deconfig -force -verbose，而非roothas.pl（已废弃）
排查私网与 IPC 层级阻断
即使网络 ping 通，CSS 仍可能因底层通信失败而报 ORA-29701：
- 检查私网接口是否被 firewalld/iptables 拦截 Unix socket 创建：
getenforce确认 SELinux 状态；临时设为 permissive 可快速验证 - 确认
/dev/shm挂载正常且空间充足（df -h /dev/shm），CSS 依赖共享内存段通信 - 查看
$GRID_HOME/log/<hostname>/cssd/ocssd.log</hostname>，搜索 “IPC connect failed”、“CLSC_” 或 “kgxgncin” 错误，这类日志比 alert.log 更早暴露连接失败根源
别忽略 udump 和 /var/tmp 空间耗尽
这不是“少见边缘情况”，而是 12c 中高频诱因——尤其当启用了 SQL Trace、ADDM 或自动任务：
- 执行
df -h /u01/app/oracle/diag/rdbms/<db_name>/<inst_name>/trace</inst_name></db_name>和df -h /var/tmp，若任一达到 95%+，立即清理旧 trace 文件（find . -name "*.trc" -mtime +7 -delete） - 特别注意
udump目录下是否有单个 >2GB 的 trace 文件（常见于DBMS_MONITOR.DATABASE_TRACE_ENABLE漏关） - 清理后必须重启
ohasd：先kill -9掉残留进程，再运行/u01/app/12.1.0/grid/bin/crsctl start has
最易被跳过的动作是验证 socket 文件权限和 /dev/shm 状态——它们不报错，但会让 ohasd 静默失败；一旦忽略，后续所有 OCR 检查、资源启动都是在无效前提下徒劳操作。
