必须先确认故障节点真实离线（crsctl check cluster -all 显示 offline 或不可达，olsnodes -n 不含该节点），再在健康节点以 oracle 用户执行 runinstaller -updatenodelist 同步 ocr 节点白名单，最后在故障节点本地以 root 执行 deletenode.sh -local 清理 gi 层级残留。
不能只删实例就完事，漏掉 runInstaller -updateNodeList 或 deletenode.sh 的执行顺序，OCR 里残留节点信息会导致后续加节点失败、DBCA 拒绝建实例。
先确认故障节点真实离线状态
这步跳过，90% 的删除操作会在后续报 PRCR-1076 或 CRS-4639 错误。必须在任意健康节点执行：
-
crsctl check cluster -all—— 输出中故障节点必须显示为OFFLINE或完全不可达（不能是UNKNOWN或卡在STARTING） -
olsnodes -n—— 输出里**不能包含**待删节点名；如果还在列表中，得先在健康节点运行crsctl delete node -n <node_name></node_name> - 登录故障节点（哪怕进 rescue 模式），检查
/etc/oracle/olr.loc和/etc/oracle/ocr.loc是否已清空或重命名；不处理，deletenode.sh会因读本地 OCR 失败直接退出
删除 DB 实例和 GI 节点注册必须分两步走
很多人试图用一个命令搞定，结果 OCR 白名单没更新，新加节点时 DBCA 直接报错 ORA-15032 或拒绝连接。
- 在健康节点以
oracle用户删实例：dbca -silent -deleteInstance -nodeName <faulty_node> -gdbName <db_unique_name> -instanceName <inst_name> -sysDBAUserName sys -sysDBAPassword "xxx"</inst_name></db_unique_name></faulty_node>（注意：该实例无需在本地运行，但必须已在集群中注册） - 紧接着仍以
oracle用户更新 OCR 中的数据库层级节点白名单：$ORACLE_HOME/oui/bin/runInstaller -updateNodeList ORACLE_HOME=$ORACLE_HOME "CLUSTER_NODES={node1,node2}" -silent——CLUSTER_NODES参数**只写存活节点**，大括号、逗号、空格都不能错，漏掉或写多一个都会让 OCR 认为配置不一致
在故障节点本地执行 deletenode.sh 才真正清理 GI 层级残留
别在健康节点上跑 $GI_HOME/oui/bin/deletenode.sh，那只是清本机 OUI 缓存，对集群零影响。
- 必须进入故障节点操作系统（单用户模式、rescue 环境均可），用 root 执行：
$GI_HOME/oui/bin/deletenode.sh -local -ignoreSysPrereqs -force——-local是关键，绕过 CRS 状态检查，否则报PRCR-1076 - 路径别写错：
19c对应$GI_HOME/oui/bin/deletenode.sh，不是$ORACLE_HOME下；混用会抛ClassNotFoundException - 执行后立刻检查
$GI_HOME/inventory/ContentsXML/install.xml，搜索<node_list></node_list>，确认该节点已从<node></node>列表中消失
手动收尾四个常被忽略的残留点
deletenode.sh 不碰这些，不清理，下次加节点时 OCR 校验失败、VIP 解析异常、ASM 磁盘绑定错乱全是它们惹的祸。
-
/u01/app/19.0.0/grid/cdata/<cluster_name>/<faulty_node>/</faulty_node></cluster_name>目录必须rm -rf -
/etc/hosts中该节点所有 VIP、SCAN VIP、GNS VIP 条目全部删干净，否则新节点启动时 DNS 解析卡住 - 若用 udev 绑定 ASM 磁盘，检查
/etc/udev/rules.d/99-oracle-asmdevices.rules是否还含该节点 WWID 规则 - 用
ocrconfig -showbackup查最近 OCR 备份，如有必要，用ocrconfig -restore回滚（仅当发现备份里含旧节点信息时才谨慎操作）
整个过程最脆弱的环节不在命令本身，而在于节点状态判断是否真实、CLUSTER_NODES 参数是否严格同步、以及 deletenode.sh 是否真正在故障节点上下文执行——这三个点任一出错，OCR 就会“记住”那个已经不存在的节点，后续所有操作都在和幻影对抗。
