物理Data Guard在11g主库与19c备库间无法同步，因块级重放要求二进制兼容，而两版本redo格式、SCN编码等均不兼容；唯一可行路径是先转逻辑DG，再升级备库，最后切换。
物理 Data Guard（ADG）在 11g 主库和 19c 备库之间根本无法同步——这不是配置技巧问题，是 Oracle 架构层面的硬性限制。想“升级期间保持容灾能力”，唯一可行路径是：先转逻辑 Data Guard，再升级备库，最后切换。任何绕过这一步的尝试，都会在 ALTER DATABASE START LOGICAL STANDBY APPLY 或后续阶段报 ORA-16700、ORA-16778 或直接卡死。
为什么物理 DG 在 11g→19c 场景下必然失败
物理 DG 依赖块级重放（Redo Apply），要求主备库二进制完全兼容。11.2.0.4 和 19c 的 redo 日志格式、SCN 编码、数据块头结构、甚至归档日志校验逻辑都完全不同。19c 的 MRP 进程根本无法识别 11g 生成的归档，反过来也一样。官方文档明确禁止该组合，不是“建议不要”，而是“根本不支持”。
常见错误现象：
-
ORA-16700：logical standby database has diverged from the primary -
ORA-16778：log transport error occurred for destination - MRP 进程持续显示
APPLYING_LOG但V$LOGSTDBY.PROCESS中无实际 SQL 应用记录
转逻辑 DG 前必须完成的三件事
逻辑 DG 用 SQL Apply 替代块重放，能跨版本运行，但对主库日志完备性和对象结构更敏感。漏掉任一检查，DBMS_LOGSTDBY.INSTANTIATE_TABLE 或后续同步就会静默丢 DML。
- 在主库执行
EXEC DBMS_LOGSTDBY.BUILD—— 初始化 LogMiner 字典；不执行会导致备库无法解析 11g redo 为有效 SQL - 确认主库已开启主键补充日志：
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS；仅ADD SUPPLEMENTAL LOG DATA不够，缺主键列日志会使 UPDATE/DELETE 丢失关键谓词 - 扫描不兼容对象：
SELECT * FROM DBA_LOGSTDBY_UNSUPPORTED和SELECT * FROM DBA_LOGSTDBY_NOT_UNIQUE WHERE BAD_COLUMN = 'Y'；遇到LONG、ROWID列或无主键表，必须提前加RELY DISABLE约束或改表结构
autoupgrade 在逻辑备库上执行的安全顺序
不能边同步边升级。SQL Apply 进程会与 autoupgrade 争抢数据字典锁，大概率触发 ORA-00054: resource busy 或升级中途挂起。
- 先停同步：
ALTER DATABASE STOP LOGICAL STANDBY APPLY - 确认
V$LOGSTDBY.STATE为IDLE或APPLYING BATCH后再执行升级 - 命令示例：
autoupgrade -mode UPGRADE -oracleHome /u01/app/oracle/product/19c -config /tmp/upgrade.conf - 升级完成后必须重建逻辑 DG：用新 19c 软件重新配置
LOG_ARCHIVE_DEST_2指向 11g 主库，并显式运行DBMS_LOGSTDBY.INSTANTIATE_TABLE补全差异对象；不能直接RESUME
切换前最后的数据一致性校验要点
从 11g 主库切到 19c 逻辑备库，不是简单 ALTER DATABASE COMMIT TO SWITCHOVER。关键动作是确保所有未传输 redo 全部落盘并应用完毕。
- 主库执行
ALTER SYSTEM ARCHIVE LOG CURRENT三次，强制归档当前日志并触发传输 - 检查
V$ARCHIVED_LOG中最大SEQUENCE#是否已在备库V$LOG_HISTORY中出现 - 确认
V$LOGSTDBY.PROCESS中STATE为WAITING FOR LOGS，且APPLIED_SCN与主库V$DATABASE.CURRENT_SCN差值 ≤ 1000 - 切换前禁用自动维护任务：
EXEC DBMS_AUTO_TASK_ADMIN.DISABLE，避免升级后因统计信息收集冲突引发锁等待
最容易被忽略的是：逻辑 DG 切换后，19c 备库的 COMPATIBLE 参数仍为 11.2.0，所有 19c 新特性（如 JSON 表函数、多租户基础能力）默认不可用。必须在切换完成、数据库 OPEN 后立即执行 ALTER SYSTEM SET COMPATIBLE='19.0.0' SCOPE=SPFILE 并重启——这步不做，等于白升。
