处理Oracle 12c RAC中常见ORA-29701集群件错误

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，搜索 “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 和 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 检查、资源启动都是在无效前提下徒劳操作。