crsctl stop crs 是强制前置动作，必须先执行：它逐级停止所有集群资源及ohasd、evmd、cssd等核心进程，否则rootcrs.pl -deconfig会因OCR/Voting Disk被锁而失败。
crsctl stop crs 为什么必须先执行，且不能跳过
卸载 grid infrastructure（gi）前，crsctl stop crs 不是可选步骤，而是强制前置动作。它会逐级停止所有集群资源（asm、监听、vip、scan 等），并终止 ohasd、evmd、cssd 等核心守护进程。跳过或仅执行 crsctl stop resources 会导致后续 deinstall 卡在“等待资源释放”或报错 crs-2501: resource 'ora.cssd' is not registered —— 因为 css 进程还在运行，ocr/voting disk 被锁住。
实操建议：
- 在所有节点上以
grid用户执行：crsctl stop crs -f（-f强制避免交互等待） - 验证是否清空：
ps -ef | grep -E "(cssd|crsd|evmd|ohasd)" | grep -v grep应无输出 - 若某节点卡住（如
cssd挂起），需手动 kill 对应进程 PID，再重试；否则rootcrs.pl -deconfig会失败
rootcrs.pl -deconfig -force 是清理注册信息的关键入口
rootcrs.pl -deconfig -force 是 Oracle 官方推荐的脱机清理起点，尤其适用于 deinstall 命令无法启动、或 GI 安装异常中断后残留配置的场景。它不删文件，但会从 OCR 中移除该节点的集群成员身份、删除本地 gpnp 配置、清理 /etc/oracle/olr.loc 和 /etc/oracle/ocr.loc 的软链接指向，并重置 ohasd 自启动状态。这一步做完，节点才真正“退出集群”，后续 deinstall 才能安全执行。
实操建议：
- 必须用
root用户，在$GRID_HOME/crs/install/下执行：./rootcrs.pl -verbose -deconfig -force -
-verbose很重要：能看到每一步操作日志，比如是否成功删除了/var/tmp/.oracle/socket 目录，或是否清理了/etc/inittab.crs - 多节点 RAC 中，**只在一个节点执行即可**；其他节点后续跑
deinstall时会自动同步清理逻辑 - 执行后检查：
cat /etc/oracle/ocr.loc应报错 “No such file”，ls -l /etc/oracle/应只剩空目录或不存在
deinstall 命令失效时，直接删 $GRID_HOME + 清理清单才是兜底方案
当 $GRID_HOME/deinstall/deinstall 报错 “cannot read inventory” 或 “no response file found”，往往说明 oraInventory 已损坏或路径混乱。此时硬等响应文件生成只会浪费时间。Oracle 19c 及以后版本中，deinstall 本质是封装了 runInstaller -removeHome + 清理脚本，而手工清理更可控、更彻底。
实操建议：
- 确认 GI 已停、
rootcrs.pl -deconfig已完成，再切换root用户执行： -
rm -rf $GRID_HOME（注意不是rm -rf /u01/app/19.0.0/grid这种硬编码路径，先echo $GRID_HOME确认） -
rm -rf /opt/oraInventory或/u01/app/oraInventory（查/etc/oraInst.loc内容定位） -
rm -f /etc/oraInst.loc /etc/oratab /etc/oracle/*（/etc/oracle整个目录可删） rm -f /usr/local/bin/dbhome /usr/local/bin/oraenv /usr/local/bin/coraenv
ASM 磁盘头不清零，重装时会报 ORA-15018 / ORA-15063
很多人以为删掉 $GRID_HOME 和 oraInventory 就算卸载干净，结果重装 GI 启动 ASM 实例时，asmcmd lsdg 显示磁盘组为空，或者 sqlplus / as sysasm 报 ORA-15063: ASM discovered an insufficient number of disks。根本原因是 ASM 磁盘头部（前 1MB）还残留旧的 disk header、kfed 识别出的旧 disk name 和 failgroup 信息，新 GI 读到脏数据后拒绝挂载。
实操建议：
- 用
root执行dd清零磁盘头（非整盘擦除，只清前 1MB）：dd if=/dev/zero of=/dev/sdb bs=1024 count=1024 - 确认设备名准确：用
ls -l /dev/disk/by-id/或blkid核对物理路径，避免误清系统盘 - 若用 UDEV 绑定，清完后重启
udev或重载规则：udevadm control --reload-rules && udevadm trigger - 清完后用
kfed read /dev/sdb验证：输出应为全 0 或报错 “unable to read”，而非显示旧的dsknum、grpname
整个过程最易被忽略的是 OCR/Voting Disk 设备本身的状态 —— 它们可能挂在裸设备、ASMLIB、UDEV 或 multipath 下，清头前没确认路径，清完后没 reload multipath，重装时就找不到盘。别省那两分钟 lsblk -f 和 multipath -ll。
