oracle 12c 不支持通过 data guard 直接跨版本升级至 19c/21c，因 redo 日志格式与内核结构不兼容，dg 仅可作为数据同步管道，需经“同步→切换→升级”三阶段人工操作实现平滑迁移。
oracle 12c 本身不支持直接通过 data guard（dg）实现跨版本升级——dg 的主备库必须是相同版本或满足官方明确允许的“兼容版本对”，比如 12.1.0.2 主库配 12.2.0.1 备库（需启用 compatible 参数对齐），但 12c 主库无法直接拉起 19c 或 21c 备库。所谓“dg 跨版本迁移”，本质是借 dg 做数据同步管道，再配合手动切换与升级动作，不是 dg 自动完成的升级。
为什么不能直接用 DG 拉起高版本备库？
DG 的物理备库依赖 Redo Apply，而 Redo 日志格式、内部数据块结构、内存管理机制在大版本间存在不兼容。Oracle 内核强制校验 DBID、COMPATIBLE 和 SOFTWARE_VERSION，一旦发现目标库版本高于源库且未在白名单中，ALTER DATABASE RECOVER MANAGED STANDBY DATABASE 会报错：ORA-16778: failed to convert redo log file 或更常见的 ORA-10562: Error occurred while applying redo。
-
12c（如12.2.0.1）的 Redo 日志无法被19c实例原生解析，除非先升级备库软件并执行RECOVER DATABASE USING BACKUP CONTROLFILE等非常规操作，但这已脱离 DG 标准流程 - Oracle 官方只允许“向后兼容”的极小范围补丁级升级（如
12.1.0.2 → 12.1.0.3），不支持12c → 19c这类跨代物理备库
实际可行的“DG 辅助平滑升级”路径
真正能落地的方案，是把 DG 当作“实时数据搬运带”，而非“自动升级引擎”。核心是三阶段：同步 → 切换 → 升级。
- 先建一个同版本的物理备库（如
12.2.0.1），确保 DG 同步稳定运行至少 24 小时，验证APPLY_LAG和TRANSPORT_LAG均为 0 - 停掉该备库，将其数据库软件升级到目标版本（如
19c），使用DBUA或手动catctl.pl升级脚本；注意：升级前必须关闭备库实例，升级后控制文件需重建或从主库重新拷贝（因19c控制文件结构变更） - 升级后的备库无法直接接管 DG 流程，需转为 Snapshot Standby（临时读写），再通过
FLASHBACK DATABASE回退到升级前 SCN，最后用逻辑复制（如 GoldenGate）或全量导出导入补差——此时 DG 已退出，只是借了它前期的数据同步能力
容易踩的坑：COMPATIBLE 参数与升级窗口陷阱
很多人忽略 COMPATIBLE 是单向锁死参数：一旦主库设为 19.0.0，就再也无法降回 12.2.0。而 DG 备库升级过程中，若主库仍运行在 12c，备库升级后若误设 COMPATIBLE=19.0.0，将导致无法再与主库同步 Redo（即使降级软件也无效）。
- 升级前必须确认主库
COMPATIBLE值 ≤ 目标备库最低要求（查 Oracle 文档的COMPATIBLE支持矩阵） - 真实停机窗口不在 DG 切换时，而在备库升级完成后、应用验证前——因为
19c的 SQL Plan Baseline、统计信息收集策略、隐式类型转换规则都与12c不同，业务 SQL 可能出现性能抖动甚至计划失效 - 别依赖
ADG（Active Data Guard）的只读开放功能来“边跑边验”，12c主库 +19cADG 备库组合不被支持，强行启动会触发ORA-600 [krsb_sga_init_3]
真正决定平滑与否的，不是 DG 是否启用，而是升级前后 SQL 执行计划稳定性、存储过程重编译成功率、以及应用连接池能否容忍短暂的 TNS 切换延迟。这些细节比“是否用 DG”重要得多。
