升级 Oracle RAC 19c 到 21c 前，必须先验证 GI 与 DB Home 的版本兼容性。由于 21c GI 与 19c GI 存在兼容限制，升级顺序一旦出错，极易引发 ASM 磁盘组挂载失败、OCR 元数据损坏等严重问题。标准做法是先使用 runInstaller -upgrade 完成 GI 升级，再执行数据库升级，同时检查 crsctl query crs activeversion 与 softwareversion 是否保持一致。
升级前必须验证 GI 和 DB Home 的版本兼容性
Oracle RAC 19c 升级到 21c 并不是简单替换数据库软件，而是同时涉及 Grid Infrastructure（GI）与 Database Home 两个层面的升级。21c 的 GI 必须与 21c 的 DB Home 配合使用，而 19c 的 GI 不能直接管理 21c 数据库实例——如果强制启动，通常会出现 ORA-01092: ORACLE instance terminated 或 CRS-2674: Start of 'ora.dbname.db' on 'node1' failed 等报错。正确流程是先将 GI 升级到 21c，再升级 DB Home；如果顺序颠倒，可能导致集群资源注册失败、ASM 实例无法挂载磁盘组，甚至影响集群稳定性。
- 必须通过
runInstaller -upgrade模式升级 GI，不能采用deinstall + install的方式，否则 OCR 与 voting disk 的元数据存在损坏风险 - 19c GI 的
root.sh脚本无法识别 21c 的内核模块签名，需提前在所有节点执行rpm -Uvh --force oracle-gridengine-21c-*.rpm（仅适用于 OL8/OL9） - 升级完成后要检查
crsctl query crs activeversion与crsctl query crs softwareversion是否一致，如差值大于 0.1，通常说明 GI 与 DB 版本存在错配
多租户容器数据库（CDB）的 PDB 兼容性陷阱
当 19c 的 CDB 升级到 21c 后，PDB 并不会自动完成升级，必须显式执行 ALTER PLUGGABLE DATABASE pdb_name UPGRADE。但如果 PDB 内存在自定义 Java 类、外部表指向 NFS 路径，或仍使用已废弃的 UTL_FILE_DIR 参数，升级过程就可能卡在 catupgrd.sql 阶段，而且错误日志往往只显示模糊的 ORA-00600: internal error code。很多情况下，真正的问题根源并不在主日志中，而是在 PDB_PLUG_IN_VIOLATIONS 视图里残留了未处理的不兼容项。
- 升级前必须运行
DBMS_PDB.CHECK_PLUG_COMPATIBILITY，并重点检查返回结果中的VIOLATION列，常见问题包括：PDB 使用了 19c 中已弃用的SEC_PROTOCOL_ERROR_TRACE_ACTION参数 - 21c 默认启用
ENABLE_PLSQL_DEBUG，若 PDB 中存在大量未编译的 PL/SQL 包体，catuppst.sql可能因编译超时而中断，建议提前执行ALTER SESSION SET PLSQL_DEBUG=FALSE - 升级后首次打开 PDB 时，
v$pdbs.status可能显示为UNUSABLE，这通常不代表数据损坏，而是后台进程正在完成元数据刷新，最长可能持续 5 分钟
RAC 特有参数在 21c 中的行为变更
进入 21c 后，Oracle RAC 的部分关键参数行为已经发生变化：_gc_read_mostly_locking 的默认值由 TRUE 调整为 FALSE，cluster_database_instances 也不再支持动态修改。此外，如果 remote_listener 仍然指向 19c 的 SCAN 地址，新节点将无法正常加入集群。麻烦在于，这类变更通常不会主动触发明显告警，但影响却非常直接——轻则跨节点查询性能下降，重则 CRS 资源持续 restart，出现反复拉起的问题。
- 升级完成后应立即检查
show parameter gc_read_mostly_locking，如果业务依赖读多数锁优化（如报表型 PDB），需手动将其调整回 TRUE srvctl modify database -d dbname -n node_count在 21c 中已不再生效，需改用ALTER SYSTEM SET cluster_database_instances = N SCOPE=SPFILE并重启数据库- SCAN 监听器需要重新创建：旧 SCAN 的 VIP 地址在 21c GI 中会被标记为 legacy，需执行
srvctl add scan -n new-scan-name，否则即使lsnrctl status显示监听正常，客户端连接仍可能随机失败
补丁冲突和 RU 应用窗口重叠
19c 的最后一个 RU 停留在 19.24（2024 年 Q2），而 21c 的第一个 RU 为 21.3（2024 年末）。Oracle RAC 19c 升级到 21c 时，一个非常常见的风险是误将 19c 的 RU 补丁用于 21c 环境，例如错误执行 opatch apply 19c_ru_patch。此时 OPatch 往往会直接报错：OPatch cannot apply the patch because it is not applicable for the current Oracle Home。但真正麻烦的不只是报错本身，还可能悄悄修改 $ORACLE_HOME/inventory/ContentsXML/comps.xml，导致后续 opatch lsinventory 输出异常，严重时甚至影响 dbca 创建新数据库。
- 升级前务必清理
$ORACLE_HOME/cfgtoollogs/opatch目录下所有 19c 补丁日志，避免 OPatch 自动加载旧补丁元数据 - 21c 安装完成后首次执行
opatch auto，必须分别指定-oh $GRID_HOME和-oh $ORACLE_HOME来处理 GI 与 DB Home，混用会触发OPATCHAUTO-72019错误 - 升级窗口期间不要执行
datapatch，因为它可能在 21c 环境中尝试调用 19c 的catbundle.sql，从而造成数据字典视图结构混乱
Oracle RAC 升级过程中，最隐蔽的风险往往不在日志报错本身，而在 CRS 资源状态与数据库真实服务能力之间存在“时间差”。例如，crsctl stat res -t 显示所有资源均为 ONLINE，但 SELECT * FROM gv$instance 却缺少某个节点实例。这种状态不一致通常会持续数分钟，足以让负载均衡器错误地将流量分发到假死节点，进而影响业务连接与集群可用性。
