节点状态为Not Configured说明集群栈未完成注册或配置信息缺失,根本原因是root.sh未成功执行完毕,需检查rootcrs.log中OCR配置、投票盘添加等关键步骤是否报错,确认OCR可访问、GI软件完整后,再执行rootcrs.sh -deconfig -force及-prepatch/-postpatch修复。
crsctl check cluster -all 显示节点状态为 Not Configured
这说明该节点的集群栈(gi)虽已安装,但未完成注册或配置信息缺失,crsctl 无法识别其为合法集群成员。常见于补丁中断、ocr/voting disk 损坏、或 root.sh 未成功执行完毕。不是单纯服务没启,而是“集群根本不认它”。
检查 $GRID_HOME/crs/install/rootcrs.log 是否存在失败记录
该日志是 root.sh 执行过程的唯一可信痕迹。重点搜以下关键词:
-
ERROR或Failed—— 尤其出现在 “OCR configuration”、“voting disk add”、“grid infrastructure config” 后面 -
PRCR-1079、CRS-2566、ORA-15032—— 表明 OCR 或 ASM 配置失败 - 末尾是否出现
Successfully configured Oracle Grid Infrastructure
若日志中途截断、无成功标记,或明确报错“OCR not accessible”,基本可判定 root.sh 半途失败。
用 cluvfy 验证 GI 软件完整性与权限
在 grid 用户下运行:
cluvfy comp software -n <failed_node> -verbose</failed_node>
注意看输出中是否出现:
-
WARNING: These nodes cannot be reached→ 网络连通性问题,先查私网 ping、防火墙、cvuqdisk包是否安装 -
Software check failed→$GRID_HOME权限损坏,需比对$GRID_HOME/crs/utl/crsconfig_dirs和crsconfig_fileperms文件,用rootcrs.pl -init修复(仅限 11.2.0.3.6+ / 19c) - 若提示
PRVG-11368: SCAN resolves to only 1 IP→ SCAN 解析异常会阻塞 GI 启动,临时注释/etc/hosts中 SCAN 条目,改用 DNS 正确解析后再重试
强制重新运行 root.sh(谨慎!需满足前提)
只有确认以下三点后才可执行:
- OCR 和 Voting Disk 仍可被其他健康节点访问(
ocrcheck、crsctl query css votedisk在正常节点上返回有效路径) - 故障节点上的
$GRID_HOME完整且未被手动修改过权限 - 该节点未被其他节点通过
crsctl delete node移除过(否则需先清理残留)
操作步骤(root 用户):
cd $GRID_HOME/crs/install<br>./rootcrs.sh -deconfig -force -verbose<br>./rootcrs.sh -prepatch<br>./rootcrs.sh -postpatch
关键点:-deconfig -force 会清除本地 GI 配置但不碰 OCR;后续 -prepatch/-postpatch 实质是安全重启配置流程。跳过直接跑 root.sh 可能因残留状态报错。
最易被忽略的是:Not Configured 状态下,crsctl start crs 一定失败,必须先让 GI 自身完成“身份注册”,而这个动作只发生在 rootcrs.sh -postpatch 或完整 root.sh 的最后阶段 —— 不是启服务,是写入集群元数据。











