执行deletenode前须确认三件事：1. crsctl check cluster -all显示故障节点为OFFLINE或不可达；2. 该节点所有Oracle进程已停，且/etc/oracle/olr.loc与ocr.loc已清空或重命名；3. olsnodes -n输出中不包含待删节点名，否则需先在健康节点执行crsctl delete node -n 。
deletenode 命令执行前必须确认的三件事
直接跑 deletenode 极大概率失败或留下残余，它不是“一键卸载”。oracle rac 的节点删除本质是反向安装流程，依赖 crs、gi、db 层级状态完全一致。你得先确认：
-
crsctl check cluster -all显示故障节点状态为OFFLINE或根本不可达（不能显示CRS-4639以外的错误） - 该节点上所有 Oracle 进程（
crsd、ohasd、oraagent等）已彻底停止，且/etc/oracle/olr.loc和/etc/oracle/ocr.loc文件已被手动清空或重命名（否则deletenode会因读取本地 OCR 配置失败而中止） - 剩余健康节点上运行
olsnodes -n，输出中**不包含**待删节点名；若仍存在，需先在健康节点执行crsctl delete node -n <node_name></node_name>手动从集群注册表移除——这是最常被跳过的前置步骤
deletenode 实际执行时的路径与参数陷阱
deletenode 不是通用命令，它位于 GI 安装目录下，且必须在**待删除节点本地**（即使已宕机，只要系统能启动到单用户模式或 rescue 环境）或通过远程挂载其根文件系统后执行。常见误操作：
- 在健康节点上执行
$GI_HOME/oui/bin/deletenode.sh -ignoreSysPrereqs -force—— 这只会清理本机 OUI 缓存，对集群无影响 - 漏掉
-local参数：当节点已无法启动 CRS，但磁盘仍可访问时，必须加-local强制绕过 CRS 检查，否则报错PRCR-1076 : Failed to get resource status - 路径写错：12c 及以后版本，脚本位置是
$GI_HOME/oui/bin/deletenode.sh，不是$ORACLE_HOME/oui/bin/；11gR2 则是$CRS_HOME/oui/bin/deletenode.sh，混用会导致ClassNotFoundException
清理后必须手动收尾的四个残留点
deletenode.sh 只处理 OUI 注册和部分配置文件，以下内容它完全不碰，不手动清理会导致下次加节点失败或 OCR 校验异常：
用于自动切换项目中适合的node 版本
下载
根据 package.json 中的 engines 字段自动检测 Node.js 版本需求，未安装 nvm 时自动安装并切换至对应版本。支持 Windows、macOS、Linux。适用于 Node.js 项目开发、版本切换和环境配置。
-
/u01/app/19.0.0/grid/cdata/<cluster_name>/</cluster_name>下残留的该节点专属目录（如node3/），必须rm -rf -
/etc/hosts中该节点的 VIP、SCAN VIP、GNS VIP 条目，漏删会导致新节点解析失败 - 如果用了 udev 绑定 ASM 磁盘，检查
/etc/udev/rules.d/99-oracle-asmdevices.rules是否还含该节点的 WWID 规则 - OCR 备份里可能存有旧节点信息：用
ocrconfig -showbackup查最近备份，再用ocrconfig -restore <backup_file></backup_file>（谨慎！仅当确认备份干净时才恢复）
验证是否真删干净：三个关键检查命令
别只信 olsnodes 输出。真正干净的标准是：
-
crsctl stat res -t | grep -i "node3"（替换为实际节点名）—— 无任何输出才算成功；若有残留资源（如ora.node3.vip），说明crsctl delete node没执行到位 -
srvctl config database -d <db_name></db_name>中的Instances:行不再列出该节点实例名 - 登录任意健康节点，执行
sqlplus / as sysasm后运行SELECT name, state FROM v$asm_diskgroup;，确认所有磁盘组state为MOUNTED—— 若出现DISMOUNTED，往往是因为该节点残留的 ASM 实例未被彻底 deregister
