物理dg跨版本同步必然失败，因11.2.0.4与19c的redo格式、数据块结构、scn机制完全不兼容，归档日志无法解析，报ora-16700/ora-16778；唯一可行路径是转逻辑dg，前提为执行dbms_logstdby.build、开启主键级补充日志、清理不支持对象。
物理备库不能直接升级到19c——11g主库和19c备库之间无法维持物理DG同步，这是Oracle硬性限制，不是配置能绕过的。
为什么物理DG跨版本同步必然失败
物理DG依赖块级重放（Redo Apply），而11.2.0.4与19c的redo日志格式、数据块结构、SCN编码机制完全不兼容。主库生成的归档日志，19c备库根本解析不了，会直接报ORA-16700或ORA-16778；反过来，11g备库也无法识别19c主库的redo。这不是“调参数就能好”的问题，是二进制层面的断裂。
唯一可行路径：转逻辑DG再升级
逻辑DG用SQL Apply替代块重放，把redo反解为DML/DDL语句执行，天然支持跨版本。但必须做完三件事才敢动：
- 在主库执行
EXEC DBMS_LOGSTDBY.BUILD，否则备库缺少LogMiner字典，连基本DML都解析失败 - 确认主库已开启主键级补充日志：
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、无主键表，必须提前加约束或改结构，autoupgrade不会帮你处理这些
autoupgrade执行前必须停SQL Apply并移除CRS注册
边同步边升级会死锁：SQL Apply进程和autoupgrade争抢数据字典锁，大概率触发ORA-00054: resource busy导致升级挂起。正确顺序是：
ALTER DATABASE STOP LOGICAL STANDBY APPLY- 查
V$LOGSTDBY.STATE确认状态为APPLYING BATCH或IDLE后再运行autoupgrade -mode UPGRADE - 升级前必须确保数据库没被CRS管理：
srvctl config database -d orcl若返回结果，说明已注册，必须先srvctl stop database -d orcl再srvctl remove database -d orcl -f——否则autoupgrade启动DBUA时会报CRS-2674直接退出
升级后重建逻辑DG，别信resume
19c备库启动后，不能直接ALTER DATABASE START LOGICAL STANDBY APPLY。必须用新19c软件重新配置LOG_ARCHIVE_DEST_2指向11g主库，并显式运行DBMS_LOGSTDBY.INSTANTIATE_TABLE补全差异对象。否则同步会卡在“找不到表定义”或“sequence不一致”。另外，切换前务必在主库执行三次ALTER SYSTEM ARCHIVE LOG CURRENT，确保最后一批redo落盘且传完——这个动作漏一次，切过去就丢数据。
