不能直接在物理Data Guard上做11g→19c滚动升级，必须先转成逻辑备库；因物理DG依赖块级重放，而11.2.0.4与19c的redo格式、数据块结构、SCN机制完全不兼容，属内核级硬性隔离，官方明确禁止，否则必报ORA-16700/ORA-16778导致同步中断。
不能直接在物理data guard上做11g→19c滚动升级，必须先转成逻辑备库（logical standby），否则必然报ora-16700/ora-16778，同步立刻中断。
为什么物理DG不支持11g主库+19c备库共存
物理Data Guard依赖块级重放（Redo Apply），而11.2.0.4和19c的redo日志格式、数据块结构、SCN编码机制完全不兼容。这不是配置能绕过的限制，是Oracle内核层面的硬性隔离。
常见错误现象：
-
ORA-16700：备库检测到主库版本不兼容，自动停止应用 -
ORA-16778：MRP进程无法解析来自11g的归档日志 - 备库
V$ARCHIVE_DEST_STATUS中STATUS显示ERROR，ERROR列明确提示“version mismatch”
官方文档明确禁止该组合——这不是“建议不要”，而是“根本不可行”。想跨版本滚动升级，唯一合法路径就是逻辑DG。
逻辑备库搭建前必须跑通的三道检查
逻辑DG不是物理DG换条命令就能切过去，它对源库结构极其敏感。跳过检查，SQL Apply启动后几秒内就会卡死在APPLYING BATCH或报ORA-16112。
在11g主库上逐项执行：
- 运行
EXEC DBMS_LOGSTDBY.BUILD：生成LogMiner字典，这是逻辑备库能解析11g redo为SQL的前提，漏掉这步，备库永远无法启动SQL Apply - 确认主键补充日志已启用：
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS；仅ADD SUPPLEMENTAL LOG DATA不够，缺主键列日志会导致UPDATE/DELETE丢失 - 扫描不兼容对象：
SELECT * FROM DBA_LOGSTDBY_UNSUPPORTED查XMLTYPE、ANYDATA、ROWID等禁用类型；SELECT * FROM DBA_LOGSTDBY_NOT_UNIQUE WHERE BAD_COLUMN = 'Y'查无主键/唯一约束的表——这些表必须加RELY DISABLE约束或重构
autoupgrade在逻辑备库上的安全执行时机
autoupgrade不能在SQL Apply运行时执行，否则会与数据字典锁激烈冲突，大概率触发ORA-00054: resource busy或升级中途静默挂起。
正确操作顺序：
- 在逻辑备库停SQL Apply：
ALTER DATABASE STOP LOGICAL STANDBY APPLY - 确认
V$LOGSTDBY.STATE返回IDLE或APPLYING BATCH（非WAITING FOR LOGS） - 执行autoupgrade：
autoupgrade -mode UPGRADE -oracleHome /u01/app/oracle/product/19c -config upgrade.conf - 升级完成后，**不能直接
RESUME**：必须用19c软件重建LOG_ARCHIVE_DEST_2，并运行DBMS_LOGSTDBY.INSTANTIATE_TABLE补全主库新增对象
切换前最后的数据一致性校验要点
从11g主库切到19c逻辑备库，不是简单发一条ALTER DATABASE COMMIT TO SWITCHOVER。关键动作是确保“最后一滴日志”被完整消费。
- 主库连续执行三次
ALTER SYSTEM ARCHIVE LOG CURRENT，强制所有未归档redo落盘并传输 - 检查主库
V$ARCHIVED_LOG中最新归档的SEQUENCE#，与备库V$LOGSTDBY_PROGRESS中APPLIED_SCN对应日志序列一致 - 禁用主库自动维护任务：
EXEC DBMS_AUTO_TASK_ADMIN.DISABLE，防止切换窗口内触发统计信息收集等后台作业干扰 - 备库确认
V$LOGSTDBY.STATE为APPLYING BATCH且EVENT_TIME持续更新，说明SQL Apply仍在实时消化新日志
最容易被忽略的是：逻辑DG切换后，原11g主库不会自动变成19c物理备库——它仍是11g实例，若要构成新高可用架构，需手动将其降级为19c的物理备库，这涉及一次独立的ADG重建过程。
