逻辑dg是唯一可行的滚动升级路径，因其基于sql apply重放dml/ddl，不依赖底层块格式，支持11g主库与19c备库跨版本同步，而物理dg因数据字典和块格式不兼容无法实现。
必须用逻辑Data Guard（Logical DG），物理DG无法跨版本同步主备库。Oracle 11g和19c的数据字典结构、块格式、内部元数据不兼容，物理DG要求主备库版本一致或仅允许小版本差（如19c→19.23），而11g→19c属于“断代升级”，物理DG在备库启动时就会报ORA-00704或ORA-00702，根本走不到应用日志那步。
为什么逻辑DG是唯一可行的滚动升级路径
逻辑DG基于SQL Apply，把主库的redo解析成DML/DDL语句，在备库上重放，不依赖底层数据块格式。这意味着：主库可以是11g，备库可以是19c，只要语法兼容、对象可映射，就能持续同步。这是实现“零停机”或“分钟级停机”的技术前提。
- 逻辑DG要求主库开启补充日志：
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;，否则部分UPDATE/DELETE无法生成完整UNDO，导致同步中断 - 不支持的DDL（如
CREATE TYPE、CREATE CLUSTER）需提前识别并规避，否则LOGSTDBY$SKIP表里没配跳过，SQL Apply进程会直接挂起 - 主库的
GLOBAL_NAMES必须为FALSE，否则19c备库在构建LogMiner字典时可能因数据库链接名不匹配失败
autoupgrade工具在逻辑DG流程中的真实作用点
autoupgrade不是用来“升级正在运行的11g实例”，而是专为“已同步完成的19c空实例+11g数据副本”设计的自动化升级执行器。它只在逻辑备库停止SQL Apply后介入：
- 先停掉
ALTER DATABASE STOP LOGICAL STANDBY APPLY;，确保备库处于静止状态 - 用
STARTUP UPGRADE启动19c实例（此时控制文件仍是11g格式，但19c可识别） - autoupgrade调用
catctl.pl并行执行catupgrd.sql，升级数据字典、重建系统视图、迁移隐含参数 - 升级完成后
SHUTDOWN IMMEDIATE再STARTUP，此时备库才真正成为功能完整的19c主库候选
注意：autoupgrade不能跳过STARTUP UPGRADE阶段——直接STARTUP会触发ORA-00704，因为11g的数据文件头和19c的校验逻辑不匹配。
Switchover切换前必须验证的三个硬性条件
哪怕逻辑DG显示APPLYING_LOG，也不代表能切。生产环境翻车最多的地方就在这里：
- 查
SELECT * FROM DBA_LOGSTDBY_PROGRESS;，确认APPLIED_SCN与主库当前CURRENT_SCN差值小于10万（建议ORA-16191 - 主库执行
EXEC DBMS_LOGSTDBY.SKIP_TRANSACTION('xidusn','xidslt','xidsqn');清理所有未提交的分布式事务，否则19c备库SQL Apply会卡在WAIT_FOR_TXN状态 - 检查
V$LOGSTDBY_STATE中STATE字段是否为APPLYING而非WAITING_FOR_LOG或IDLE；后者说明归档传输链路中断过，需手动COPY缺失归档并REGISTER
切换命令本身很简单：ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN;，但前提是上面三项全绿。少验一项，就可能卡在ORA-16475（等待远端确认）或ORA-16139（日志未完全应用），凌晨两点救火就是这么来的。
