Oracle RAC 卸载：那些脚本不会告诉你的关键步骤

说到卸载Oracle RAC，很多人第一反应是找到deinstall脚本，然后一键回车。但现实往往没那么简单。直接运行脚本，很可能在某个环节卡住，或者看似卸载成功，重装时却遇到各种“灵异”错误。这背后的原因，恰恰在于自动化工具无法覆盖所有的手动清理和状态检查。下面就来拆解几个核心环节，看看如何彻底、干净地移除一个RAC环境。

deinstall 脚本能不能直接卸掉整个 RAC？

答案是：不能指望一锤子敲完。Oracle的deinstall工具采用的是分层卸载逻辑，它并不会自动判断“先删数据库还是先删Grid”，更不会跨用户（oracle和grid）统一执行。实际操作中，必须按照角色和顺序，手动触发两次——先用oracle用户卸载数据库软件，再用grid用户卸载Grid Infrastructure。跳过任何一层，OCR、ASM磁盘、集群服务等残留都会像埋下的地雷，导致后续重装功亏一篑。

为什么必须先停集群再跑 deinstall？

这是很多踩坑经验的起点。deinstall脚本在运行时，会调用集群就绪服务（CRS）的接口进行资源检查和清理。如果此时集群还在运行，或者资源状态异常（比如部分离线），脚本大概率会卡在“网络配置检查”或“EMCA取消配置”这类阶段。常见的报错包括CRS-4640: Oracle High A vailability Services is not running，或者脚本直接静默退出。这并非工具缺陷，而是一种保护机制。

所以，正确的姿势是：

• 每个节点都以root用户执行：crsctl stop crs。
• 然后确认没有残留进程：ps -ef | grep -E "(ora_|d.bin|ohasd|cssd)"，如果发现，果断kill -9处理。
• 别只凭感觉判断集群停了，用crsctl check cluster -all命令验证才算数。

卸载后那些 rm -f 命令到底删什么？

deinstall脚本主要职责是清理$ORACLE_HOME目录和软件注册信息，对于系统级的痕迹，它可不会越俎代庖。而这些残留，正是新安装发生冲突的常见根源。例如，/etc/oratab里若还留着旧实例名，DBCA建库时就可能误读；/etc/init.d/ohasd如果没删干净，可能导致系统启动时自启失败甚至挂起。

因此，需要在每个节点（注意，不是只在主节点）执行以下清理：

• 删除系统配置文件：rm -f /etc/init.d/ohasd /etc/oracle/* /etc/oraInst.loc /etc/inittab.crs /etc/ohasd
• 清理临时通信通道：rm -rf /var/tmp/.oracle /var/tmp/* /var/tmp/.*
• 移除软链接入口：rm -f /usr/local/bin/{dbhome,oraenv,coraenv}
• 最后，删除安装根目录：rm -rf /u01/app/* /u01（这里的路径请务必根据你实际的$ORACLE_HOME进行调整）

ASM 磁盘和 OCR 不清，等于白卸

这是最关键的步骤之一，也最容易遗漏。deinstall脚本不会触碰ASM磁盘设备本身，更不会进行格式化。如果保留了原有的磁盘组（比如+DATA），下次安装建库时，ASM实例很可能识别出旧的磁盘组头信息，进而抛出ORA-15032或ORA-15017这类错误，或者错误挂载旧的数据文件。

彻底清理的流程如下：

• 首先列出ASM磁盘：oracleasm listdisks
• 逐个删除磁盘注册：oracleasm deletedisk DISK1
• 关键一步：物理清零：dd if=/dev/zero of=/dev/mapper/vg_ocr-lv_ocr bs=1M count=100（请将路径替换为你真实的ASM设备路径）
• 如果存储硬件支持，直接在SAN或NAS存储层面对LUN进行重新初始化，这通常比在操作系统层用dd命令更为彻底。

同样，存放OCR和Voting Disk的磁盘也必须清理。这一步如果漏掉，即使运行rootcrs.pl -deconfig -force也可能失败。后果就是，重新安装Grid时，安装程序会卡在“Creating OCR backup”这一步无限等待。

说到底，卸载RAC更像是一次精密的外科手术，而非简单的拆除。自动化脚本提供了主要框架，但那些边边角角、深藏不露的“组织”，还得靠手动工具一点点剥离干净。遵循分步、分角色、彻底清理的原则，才能为下一次的全新安装铺平道路。