物理备库跨版本同步不可行，因redo格式、数据块结构和scn编码存在内核级不兼容；逻辑备库可行但须执行dbms_logstdby.build、启用主键补充日志、清理不兼容对象三步，缺一即同步失败。
Oracle Data Guard 跨版本同步物理备库不可行，逻辑备库可行但限制极多——这不是配置技巧问题，而是 Oracle 架构层面的硬性约束。
物理DG 为什么跨版本必然失败
物理 Data Guard 依赖块级重放（Redo Apply），主备库必须二进制兼容：
-
11g与19c的 redo 日志格式、数据块结构、SCN 处理机制完全不同 -
12c主库发出的归档日志，19c的 MRP 进程根本无法识别，启动即报ORA-16470或直接拒绝接收 - 官方文档明确禁止跨主版本（如 12.1 → 19.x）直接搭建物理备库，不是“调参能解决”，是底层不支持
常见错误现象：
- 备库
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE后卡在WAITING FOR ARCHIVE LOG - 主库
ARCHIVE_LAG_TARGET生效但备库归档始终不应用，V$ARCHIVED_LOG中APPLIED = 'NO' - 查
V$DATAGUARD_STATS显示transport lag持续增长，apply lag为UNKNOWN
逻辑DG 是唯一可行路径，但三件事不做必崩
逻辑 Data Guard 使用 SQL Apply，绕过块结构差异，可跨大版本运行，但代价是兼容性检查更严：
- 必须在主库执行
EXEC DBMS_LOGSTDBY.BUILD：否则备库 LogMiner 无法解析 11g/12c 的 redo 字典，SQL Apply 启动即报ORA-16111 - 必须开启主键级补充日志：
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS；仅ADD SUPPLEMENTAL LOG DATA不够，DML 会丢行 - 必须提前清理不兼容对象：
-
SELECT * FROM DBA_LOGSTDBY_UNSUPPORTED：含LONG、ROWID、BFILE等类型表需改造或排除 -
SELECT * FROM DBA_LOGSTDBY_NOT_UNIQUE WHERE BAD_COLUMN = 'Y'：无主键且无非空唯一索引的表，必须加RELY DISABLE约束或补主键
-
漏做任意一项，SQL Apply 启动后几秒内就会报 ORA-16116（no work available）或卡在 APPLYING 状态不动。
滚动升级 场景下逻辑DG的实际操作边界
用逻辑 DG 做跨版本升级（如 11g → 19c），核心是“先转逻辑，再升备库”：
- 主库保持 11g 不动，逻辑备库从 11g 同步数据，同时升级数据库软件至 19c
- 升级前必须停
SQL Apply，升级后手动重建 LogMiner 字典（EXEC DBMS_LOGSTDBY.INSTANTIATE_LOGICAL_STANDBY） - 切换前必须校验 SCN 一致：
SELECT CURRENT_SCN FROM V$DATABASE在主备库比对，差值超过 1000 就不能切 - 切换前禁用自动维护任务（
DBMS_AUTO_TASK_ADMIN.DISABLE），否则 19c 自动统计任务可能锁表阻塞 SQL Apply
性能影响明显：
- SQL Apply 解析速度远低于物理 MRP，高并发 DML 下延迟可达分钟级
-
LOGSTDBY$EDS_TABLES和LOGMNR_SESSION表会持续膨胀，需定期EXEC DBMS_LOGSTDBY.PURGE_LOG
跨版本同步真正的难点不在“能不能做”，而在于“哪些对象不能同步”和“哪一步校验被跳过了”。一个没加主键的订单明细表、一次忘了跑 DBMS_LOGSTDBY.BUILD、甚至备库升级后没重跑 catuppst.sql，都会让同步在切换前最后一刻彻底中断。
