Oracle RAC 19c升级到21c有哪些风险

必须验证GI和DB Home版本兼容性，因21c GI与19c GI互斥，顺序错误会导致ASM挂载失败、OCR元数据损坏；需先用runInstaller -upgrade升级GI，再升级DB，并检查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；顺序颠倒会导致集群资源注册失败、ASM 实例无法挂载磁盘组。

1. 必须用 runInstaller -upgrade 模式升级 GI，不能用 deinstall + install，否则 OCR 和 voting disk 元数据可能损坏
2. 19c GI 的 root.sh 脚本不识别 21c 的内核模块签名，需提前在所有节点执行 rpm -Uvh --force oracle-gridengine-21c-*.rpm（仅限 OL8/OL9）
3. 升级后检查 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 视图里残留的不兼容项。

1. 升级前必须运行 DBMS_PDB.CHECK_PLUG_COMPATIBILITY，并检查返回的 VIOLATION 列，常见违规包括：PDB 使用了 19c 已弃用的 SEC_PROTOCOL_ERROR_TRACE_ACTION 参数
2. 21c 默认启用 ENABLE_PLSQL_DEBUG，若 PDB 中有大量未编译的 PL/SQL 包体，catuppst.sql 会因编译超时中断，需提前执行 ALTER SESSION SET PLSQL_DEBUG=FALSE
3. 升级后首次打开 PDB 时，v$pdbs.status 可能为 UNUSABLE，不是数据损坏，而是等待后台进程完成元数据刷新，最长需 5 分钟

RAC 特有参数在 21c 中的行为变更

21c 对 RAC 关键参数做了静默调整：_gc_read_mostly_locking 默认从 TRUE 改为 FALSE，cluster_database_instances 不再允许动态修改，remote_listener 若仍指向 19c 的 SCAN 地址，会导致新节点无法加入集群。这些变更不会触发告警，但会引发跨节点查询性能陡降或 CRS 资源反复 restart。

1. 升级后立即检查 show parameter gc_read_mostly_locking，若业务依赖读多数锁优化（如报表类 PDB），必须手动设回 TRUE
2. srvctl modify database -d dbname -n node_count 在 21c 中已失效，改用 ALTER SYSTEM SET cluster_database_instances = N SCOPE=SPFILE 并重启
3. 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 年末）。升级过程中若试图在 21c 环境下回退应用 19c 的 RU 补丁（例如误操作执行 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 创建新库失败。

1. 升级前务必清空 $ORACLE_HOME/cfgtoollogs/opatch 下所有 19c 补丁日志，避免 OPatch 自动加载旧补丁元数据
2. 21c 安装后首次运行 opatch auto 必须指定 -oh $GRID_HOME 和 -oh $ORACLE_HOME 分别处理 GI 和 DB，混用会触发 OPATCHAUTO-72019 错误
3. 升级窗口内禁止执行 datapatch，它会在 21c 环境中尝试调用 19c 的 catbundle.sql，造成数据字典视图结构错乱

RAC 升级最隐蔽的风险不在日志报错里，而在 CRS 资源状态与数据库实际服务能力的“时间差”——比如 crsctl stat res -t 显示所有资源 ONLINE，但 SELECT * FROM gv$instance 却漏掉某个节点的实例。这种不一致往往持续数分钟，足够让负载均衡器把流量导到假死节点上。