crsctl delete node必须在健康节点执行，不能在故障节点运行，因其依赖在线GI进程；需满足olsnodes含该节点名且其状态为OFFLINE或不可达，否则命令失败或残留元数据。
crsctl delete node 必须在健康节点执行，不能在故障节点上跑
命令 crsctl delete node -n <node_name></node_name> 是唯一能从 OCR、CSS 和 CRS 元数据中逻辑抹除节点的入口，但它**根本无法在故障节点本地运行**——该节点 GI 进程已挂，crsctl 会直接报 PRCR-1076 或无限 hang 住。必须在其余在线节点（如 rac1）上以 root 执行，且要求：olsnodes -n 输出里还包含待删节点名（说明 OCR 尚未自动标记其离线）；目标节点当前状态为 OFFLINE 或完全不可达（crsctl check cluster -all 显示超时或 CRS-4639）。
srvctl remove instance 失败时，得手动清理 OCR 里的残留资源
如果 srvctl remove instance -d orcl -i orcl2 报 “instance does not exist”，但 srvctl config database -d orcl 仍显示该实例，说明 OCR 中还有 dangling 资源。此时需人工定位并强制删除：
- 查资源名：
crsctl stat res -w "TYPE = ora.database.type" | grep -A 2 orcl，找到类似ora.orcl.orcl2.inst的条目 - 删实例资源：
crsctl delete resource ora.orcl.orcl2.inst -f - 删对应 ASM 实例（如有）：
crsctl delete resource ora.rac2.ASM2.asm -f - 删 VIP：
crsctl delete resource ora.rac2.vip -f
注意：这些操作只是清理 OCR 注册项，不更新 inventory，后续必须配合 runInstaller -updateNodeList。
deletenode.sh -local 必须在故障节点本地执行，且 GI 已停干净
$GI_HOME/oui/bin/deletenode.sh -local 是清理 OUI registry、本地 oraInst.loc、临时文件和部分 GI 配置的最后一步，但它有个硬前提：目标节点上 crsctl stop crs 必须已成功执行，且 crsctl stat res -t -n <node_name></node_name> 显示所有 CRS 资源（含 ora.asm、ora.netns）均为 OFFLINE。常见错误是只停了数据库实例（srvctl stop instance），忘了停 GI，导致脚本中途失败并留下半残状态。
最容易被忽略的三类残留：udev、密码文件、listener.ora
退役后集群看似正常，但几小时后可能突然心跳异常或 GI 启动失败，问题往往藏在这三处：
-
/etc/udev/rules.d/99-oracle-asm.rules没删：新节点加盘时 udev 规则冲突，ASM 磁盘权限错乱 -
orapw<dbname></dbname>仍含退役节点的远程登录条目：DG 备库同步时因密码文件大小不一致卡住 MRP -
$ORACLE_HOME/network/admin/listener.ora里还有该节点的SID_LIST条目：新实例启动时尝试注册不存在的 SID，日志刷满TNS-12514
真正干净的退役，不是让节点“不工作”，而是让集群元数据彻底忘记它——OCR、inventory、udev、网络配置、密码文件，缺一漏一都可能在下次补丁或重启时爆发。
