oracle 19c rac退役节点必须严格按crsctl delete node（健康节点执行）→本地deletenode.sh -local→runinstaller -updatenodelist三步闭环操作，缺一不可；否则ocr/crs残留将导致心跳异常、gi启动失败或节点驱逐。
直接说结论：Oracle 19c RAC 中退役一个节点，不能靠“停服务+删进程”硬下线，必须走 crsctl delete node + root.sh 回滚 + ASM磁盘权限清理三步闭环，否则残留的 OCR/CRS 注册项会导致集群心跳异常、GI 启动失败，甚至引发节点驱逐。
为什么 srvctl stop instance 和 shutdown immediate 不算真正退役
这只是终止数据库实例和监听，底层 Grid Infrastructure 仍认为该节点是集群合法成员：
-
crsctl check cluster -all仍会显示该节点在线（即使 GI 进程已停） - OCR 中仍存有该节点的
ora.<db>.INST_<n></n></db>资源、VIP、SCAN VIP 绑定记录 - ASM 实例启动时若发现原节点的 udev 权限或 ASMLIB 标签未清理，可能拒绝挂载磁盘组
- 后续打 RU 补丁或执行
opatchauto apply会因节点状态不一致报错PRCR-1079或CLSRSC-463
crsctl delete node 执行前必须满足的 4 个硬条件
缺一不可，否则命令直接失败或留下半残状态：
- 目标节点 GI 必须已完全停止：
crsctl stop crs（不是crsctl stop cluster） - 所有 CRS 资源（含
ora.asm、ora.ons、ora.netns）在该节点上状态为OFFLINE，用crsctl stat res -t -n <node_name></node_name>确认 - 主节点（保留节点）上执行，且当前用户需具备 root 权限并能 ssh 免密登录目标节点
- OCR 备份必须有效——执行前务必运行
ocrconfig -showbackup，确认最近一次自动备份在 4 小时内；否则先手工备份：ocrconfig -manualbackup
退役后最容易被忽略的 3 类残留项
它们不会立刻报错，但会在数小时或下次集群重启时暴露：
-
udev 规则残留：老旧节点上
/etc/udev/rules.d/99-oracle-asm.rules未删除，导致新节点添加磁盘时权限错乱 -
密码文件未同步更新：
orapw<dbname></dbname>仍含已退役节点的远程登录条目，备库 DG 同步时可能因密码文件大小不一致卡住 MRP -
监听配置未清理：
$ORACLE_HOME/network/admin/listener.ora中仍有该节点的SID_LIST条目，新实例启动时可能尝试注册不存在的 SID，日志刷满TNS-12514
真正干净的退役，不是让节点“不工作”，而是让集群元数据彻底忘记它。OCR 里没记录、ASM 不认它、监听不找它——这三件事做完，才算落地。
