物理备库不能直接升级到19c，因redo格式、数据块结构和scn编码存在内核级不兼容，必须先转为逻辑备库；转换需执行dbms_logstdby.build、启用主键补充日志、检查不支持对象，并在sql apply停止后运行autoupgrade；切换后须调整compatible参数并处理空字符串、utl_file_dir等兼容性问题。
不能直接升级物理备库到19c——这是内核级硬性限制，强行操作必然触发 ora-16700 或 ora-16778，同步立即中断。
为什么物理DG不支持11g主库+19c备库共存
物理Data Guard依赖块级重放（Redo Apply），而11.2.0.4与19c在以下层面完全不兼容：
-
redo日志格式：字段语义、校验方式、压缩逻辑均重构 - 数据块结构：
ktfbh头字段长度、空闲空间管理机制变更 - SCN编码机制：11g用32位基础+扩展，19c改用64位统一编码，无法双向解析
这不是参数或配置能绕过的——V$ARCHIVE_DEST_STATUS.ERROR 会明确显示 "version mismatch"，官方文档直接标注为“Not Supported”。
必须先转成逻辑备库才能升级
逻辑DG基于SQL Apply，把主库的redo解析为DML/DDL再执行，天然规避块结构差异。但转换不是执行一条命令就行，漏掉任一检查，SQL Apply 启动后几秒就卡死或报 ORA-16112。
- 在11g主库上运行
EXEC DBMS_LOGSTDBY.BUILD：生成LogMiner字典，否则备库根本无法解析11g redo - 启用主键级补充日志：
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS（仅ADD SUPPLEMENTAL LOG DATA不够） - 扫描禁用对象：
SELECT * FROM DBA_LOGSTDBY_UNSUPPORTED查XMLTYPE、ANYDATA；SELECT * FROM DBA_LOGSTDBY_NOT_UNIQUE WHERE BAD_COLUMN = 'Y'查无主键/唯一约束表——这些表必须加RELY DISABLE约束或重构
autoupgrade必须在SQL Apply停止后执行
autoupgrade和SQL Apply会争抢数据字典锁，同时运行大概率触发 ORA-00054: resource busy 或静默挂起。
- 停应用：
ALTER DATABASE STOP LOGICAL STANDBY APPLY - 确认状态：
SELECT STATE FROM V$LOGSTDBY返回IDLE或APPLYING BATCH（不能是WAITING FOR LOGS） - 执行升级：
autoupgrade -mode UPGRADE -oracleHome /u01/app/oracle/product/19c -config upgrade.conf - 升级完成后不能直接
RESUME：必须先用19c软件重启实例，再手工启动SQL Apply
切换前最容易被忽略的兼容性陷阱
即使逻辑同步跑通、autoupgrade成功，切换后业务仍可能异常——因为19c默认关闭了11g遗留特性，且部分语法行为已变更：
-
COMPATIBLE参数仍为'11.2.0'：必须手动执行ALTER SYSTEM SET COMPATIBLE='19.0.0' SCOPE=SPFILE并重启，否则新特性（如JSON_TABLE、ADG加密）不可用 - 11g中允许的空字符串插入（
''）在19c中默认转为NULL，应用层若未适配会丢数据 -
UTL_FILE_DIR在19c已废弃，但逻辑同步仍会重放含该参数的DDL，导致备库启动失败
真正平滑的关键，不在升级动作本身，而在对这些隐性兼容性断层的提前识别和修补。
