Oracle RAC集群的升级历来是DBA面试和实际运维中的高频话题。相比单实例数据库，RAC环境多了一层Grid Infrastructure（GI），升级时既要保证集群件本身平滑过渡到新版本，又要保证数据库实例（DB）在集群框架升级后能够继续正常运行。整个流程环环相扣，任何一步顺序颠倒都可能造成节点驱逐甚至集群瘫痪。本文结合一套11.2.0.4升级到19c的两节点RAC环境的实操经验，把GI升级和DB升级的完整过程、命令细节以及回退思路梳理清楚。
升级前的准备工作：预检查比操作更重要
RAC升级失败的原因大部分不在升级命令本身，而在前期准备不充分。首先要在所有节点上运行Oracle官方提供的集群校验工具runcluvfy，这个工具在新版本GI软件的解压目录里就能找到。执行命令类似下面这样：
./runcluvfy.sh stage -pre crsinst -upgrade -n rac1,rac2 \ -src_crshome /u01/app/11.2.0/grid \ -dest_crshome /u01/app/19.0.0/grid \ -dest_version 19.0.0.0.0 -fixup -verbose
这个命令会检查操作系统内核参数、磁盘空间、网络配置、用户组、ssh互信等几十项内容。检查结果中出现的WARNING需要逐条确认，ERROR则必须修复后重新跑一遍。经验上特别容易出问题的是/tmp空间不足、cvuqdisk包版本过低以及grid用户的ssh等效性配置失效，这三项建议优先排查。
其次是备份工作。OCR和voting disk在升级前必须备份，11.2以后OCR默认放在ASM里，可以用ocrconfig手动导出一份：
ocrconfig -export /backup/ocr_backup_$(date +%Y%m%d).dmp
同时还要确认数据库本身有可用的全量备份，ASM的spfile、密码文件位置记录清楚。另外要提前下载好新版本的GI安装包和最新的RU补丁，两节点软件的patch版本必须完全一致，否则升级到一半会报版本不匹配错误。操作系统层面，检查所有节点的时间同步服务，19c对NTP或Chrony的要求比旧版本更严格，时间偏差过大可能直接导致节点加入集群失败。
GI升级的详细步骤：滚动升级与rootupgrade.sh
GI升级支持滚动方式，即先升级一个节点，集群仍然运行在另一个节点上，业务不中断；如果不支持滚动（比如从非常老的版本跨大版本升级），则需要停机升级。以滚动升级为例，先在第一个节点用grid用户启动runInstaller，选择升级现有GI的选项，指向旧的Grid Home，安装过程只复制软件，不会切换集群配置。
安装界面执行到最后会提示以root身份在每个节点分别执行rootupgrade.sh，这是整个升级最关键的一步。第一个节点执行时脚本会停在一个提示信息处，大意是集群软件已在此节点配置完成，需要准备滚动升级其他节点，此时不要关闭窗口，去第二个节点执行同样的脚本：
/u01/app/19.0.0/grid/rootupgrade.sh
第二个节点脚本执行完成并输出Successfully setup Oracle Grid Infrastructure后，第一个节点的脚本才会继续往下走并最终结束。两个节点都完成后，用crsctl查询集群状态确认版本已经切换：
crsctl query crs softwareversion -all crsctl stat res -t
升级后要注意一点：19c的GI Home目录结构发生了变化，不能再像11g那样直接在原目录打补丁，GI HOME变为只读，补丁要打到旁边的patch目录。如果升级后资源状态有OFFLINE的，先看alert日志定位，多数是监听端口冲突或ASM参数文件路径问题。
DB升级的两种方式：DBUA图形化与手动升级
GI升级完成后，数据库本身还运行在旧版本上，此时需要升级DB。第一种方式是DBUA图形化工具，在新版本的ORACLE_HOME下执行dbua，选择要升级的RAC数据库，工具会自动检查兼容参数、失效对象、回收站等前置条件，然后对所有实例执行升级。DBUA的优点是自动化程度高，会自动处理catctl并行升级数据字典，整个19c升级在数据量不大时通常半小时到一个小时就能完成。缺点是对错误的中断恢复不够友好，一旦中途失败，重跑前需要仔细清理现场。
第二种是手动方式，适合对过程要求完全可控的场景。大致流程是：先用旧版本DBMS_STATS收集统计信息、运行preupgrade.jar做升级前检查并执行fixup脚本，然后正常关闭数据库，修改ORACLE_HOME指向新版本后以upgrade模式启动一个实例，执行catctl.pl：
cd $ORACLE_HOME/rdbms/admin $ORACLE_HOME/perl/bin/perl catctl.pl -n 4 catupgrd.sql
其中-n参数指定并行度，一般设为CPU核数的四分之一左右。升级完成后执行utlrp.sql编译失效对象，再跑postupgrade检查确认组件状态全部为VALID。无论哪种方式，升级前都要把COMPATIBLE参数保持原值，等新版本稳定运行一段时间后再考虑调高，因为COMPATIBLE一旦调高就无法回退。
升级结束后的验证不可省略：检查dba_registry中所有组件版本、确认ASM磁盘组兼容性参数、测试业务连接和RAC的故障切换功能，观察几天alert日志无异常后，才算整个升级真正落地。
常见报错与回退思路
实际操作中几个高频报错值得提前了解。一是rootupgrade.sh执行时报INS-40404错误，通常是主机SCAN配置或DNS解析问题，检查/etc/hosts中SCAN地址与nslookup结果是否一致。二是DBUA报数据库含有SYS拥有的失效对象拒绝升级，需要先执行utlrp.sql修复或在预检查报告中按提示处理。三是升级后ASM实例无法启动，多见于ASM的spfile还在旧GI Home下，需要用asmcmd或pfile重新指定位置。
回退方面，GI升级如果中途失败，可以执行crsctl config命令相关回退流程，或在rootupgrade.sh失败时直接按屏幕提示的恢复命令操作，恢复到旧Grid Home。DB升级由于修改了数据字典，回退成本极高，基本只能依赖升级前的全量备份做恢复，这也是为什么备份环节绝不能省。稳妥的做法是搭建一个与生产相同的测试环境完整演练一遍，把每一步的耗时和坑都记录下来，正式升级时按清单执行，风险就能降到最低。
Oracle RACGI升级数据库升级修改时间：2026-09-15 00:32:37