节点状态为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
注意看输出中是否出现：
-
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 的最后阶段 —— 不是启服务，是写入集群元数据。
