逻辑DG是唯一可行的滚动升级路径，因其基于SQL Apply重放DML/DDL，不依赖底层块格式，支持11g主库与19c备库跨版本同步；物理DG因数据字典和块格式不兼容无法实现。
Data Guard 本身不能直接用于跨大版本（如 11g → 19c）的主备同步——它明确不支持。你看到的“用 Data Guard 升级”其实是分阶段的组合策略，不是单纯打开 DG 就能跑通。
下面说清楚怎么做、为什么这么拆、以及最容易卡在哪一步。
为什么 Data Guard 在 11g→19c 场景中必须配合其他手段
Oracle 官方文档明确限制：Data Guard 要求主库和备库的数据库版本必须相同（至少主版本号一致），补丁集可有微小差异。11g 和 19c 属于完全不同的代码基线，LGWR 传输的重做日志格式、SCN 解析逻辑、甚至数据块结构都有本质变化。强行配置会立刻报错：ORA-16664: unable to receive the result from a database 或 ORA-10562: Error occurred while applying redo to data block。
- 这不是配置问题，是底层不兼容
- 你无法让 11g 主库实时把日志喂给 19c 备库并正确应用
- 所以所谓“DG 升级方案”，实际是“DG + 中间过渡库”或“DG + 逻辑复制桥接”
可行路径：用 12c/18c 作中间站，构建双段 DG 链路
这是生产环境验证过的折中方案：先建一个 12.2 或 18c 的物理备库接 11g 主库，再以该库为新主库，用逻辑备库方式向 19c 同步。逻辑备库允许跨大版本，但要求表结构兼容（无不支持的数据类型、无加密列等）。
- 第一段（11g → 12.2/18c）：用标准物理
Data Guard，启用LOG_ARCHIVE_DEST_2+STANDBY REDO LOG，确保归档连续 - 第二段（12.2/18c → 19c）：必须用
LOGICAL STANDBY，且需提前在 12.2/18c 上运行DBMS_LOGSTDBY.BUILD，并在 19c 上执行ALTER DATABASE START LOGICAL STANDBY APPLY - 关键约束：
LOGICAL STANDBY不支持某些 DDL（如ALTER SYSTEM、CREATE MATERIALIZED VIEW），升级前需审计所有变更脚本 - 性能影响：逻辑应用比物理应用慢 3–5 倍，高峰业务期需预留足够延迟缓冲
更稳妥的做法：用 GoldenGate 替代第二段，避免逻辑备库限制
如果业务表含 XMLType、SecureFile LOB 或大量 DDL 变更，LOGICAL STANDBY 很可能中途报错中断。此时应换用 Oracle GoldenGate（OGG）作为 12c/18c 到 19c 的同步层。
- OGG 12.3+ 支持 11g 源端 + 19c 目标端，通过抽取 trail 文件 + 应用进程解码，绕过 Oracle 内核版本校验
- 注意：OGG 需在源库开启补充日志（
ADD SCHEMATRANDATA）和强制日志模式（FORCE LOGGING） - OGG 进程状态监控必须接入告警（如
GGSERR.log中出现ERROR OGG-01163表示数据类型映射失败） - 停机窗口只发生在最后切换时刻：停 11g 写入 → 等 OGG 追平 → 切流量到 19c → 验证一致性
最容易被忽略的三个细节
很多人按步骤做完，切换时仍失败，问题往往出在这些地方：
-
TIME_ZONE版本不一致：11g 默认使用旧时区文件（timezlrg.datv14），19c 要求 v26+；未更新会导致SYSTIMESTAMP同步错乱，OGG 报OGG-01223 - 密码文件未同步或
REMOTE_LOGIN_PASSWORDFILE参数不匹配：主备间sys认证失败，ALTER DATABASE RECOVER MANAGED STANDBY DATABASE会卡住 - 19c 默认启用
COMPATIBLE=19.0.0，但若从 11g 导入的表空间含SECUREFILE加密，需在 19c 中显式设置ENCRYPTION_WALLET_LOCATION，否则备库启动即报ORA-28365
跨大版本迁移没有银弹。Data Guard 是骨架，但 11g→19c 这一跳，必须靠中间版本或 GoldenGate 填坑。真正决定停机时间长短的，不是工具选型，而是对时区、密码文件、加密配置这些“非核心参数”的检查颗粒度。
