必须验证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 实例无法挂载磁盘组。
- 必须用
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 对 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（2021 年末）。升级过程中若试图在 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 创建新库失败。
- 升级前务必清空
$ORACLE_HOME/cfgtoollogs/opatch下所有 19c 补丁日志，避免 OPatch 自动加载旧补丁元数据 - 21c 安装后首次运行
opatch auto必须指定-oh $GRID_HOME和-oh $ORACLE_HOME分别处理 GI 和 DB，混用会触发OPATCHAUTO-72019错误 - 升级窗口内禁止执行
datapatch，它会在 21c 环境中尝试调用 19c 的catbundle.sql，造成数据字典视图结构错乱
RAC 升级最隐蔽的风险不在日志报错里，而在 CRS 资源状态与数据库实际服务能力的“时间差”——比如 crsctl stat res -t 显示所有资源 ONLINE，但 SELECT * FROM gv$instance 却漏掉某个节点的实例。这种不一致往往持续数分钟，足够让负载均衡器把流量导到假死节点上。
