不能直接用物理DG跨平台升级到19c，必须转逻辑DG或换方案；因物理DG要求平台兼容、版本差≤1大版本、字节序一致，而11g→19c违反内核硬限制，必然失败。
不能直接用物理dg跨平台升级到19c——必须转逻辑dg或换方案。
Oracle 11g 的物理 Data Guard（物理DG）本身不支持跨平台 + 跨大版本（如11g→19c）的组合迁移。你看到的“DG跨平台迁移”案例，基本都限定在：同版本（如11.2.0.4→11.2.0.4）、或仅跨平台（Windows→Linux）、或仅跨小版本（11g→12c），且需严格满足字节序、补丁、参数等前提。一旦叠加“11g→19c”这种跨度，物理DG链路会在open备库或upgrade阶段直接失败。
真正可行的路径只有两条：逻辑DG + autoupgrade，或Transportable Tablespace（TTS）+ Data Pump。前者适合业务连续性要求高、停机窗口极短的场景；后者适合可接受数小时停机、但数据量可控（
为什么物理DG在11g→19c跨平台时必然失败
物理DG依赖块级复制，要求主备库：
- 操作系统平台兼容（查
v$transportable_platform确认） - 数据库版本差异 ≤ 1个大版本（官方明确禁止11g→19c物理备库）
- 字节序一致（
endian_format必须相同） - 所有补丁集对齐（如11.2.0.4 + Patch 13104881 才支持 Windows→Linux 物理DG）
alter database open，大概率报 ORA-01589、ORA-00704 或直接实例崩溃。这不是配置问题，是Oracle内核层面的硬限制。
逻辑DG是唯一支持11g→19c滚动升级的DG路径
逻辑DG把redo解析成SQL再执行，绕过了物理块兼容性问题，因此允许跨平台、跨大版本。但它有严苛前提：
- 主库必须开启
supplemental logging（add supplemental log data） - 所有待同步表必须有主键或唯一约束（否则DML被跳过）
- 不支持某些对象类型：LOB with BASICFILE、物化视图日志、调度作业、外部表
- 备库升级前，必须先停止逻辑应用：
alter database stop logical standby apply
autoupgrade 工具（需提前部署19c home并配置autoupgrade.jar）→ 升级完成 → 重启为19c → 重新启用逻辑应用。整个过程主库11g持续提供服务。
TTS+Data Pump更适合中小规模、可控停机的跨平台迁移
当逻辑DG改造成本过高（如大量无主键表、LOB密集），TTS是更直接的选择，但必须验证三项：
-
SELECT platform_name, endian_format FROM v$transportable_platform—— 源/目标平台字节序必须一致（如都是Little Endian） -
DBMS_TTS.TRANSPORT_SET_CHECK返回空结果（即表空间自包含） - 目标库19c必须提前创建好对应用户、目录（
CREATE DIRECTORY dump_dir AS '/u01/dump'）、字符集兼容
- 源库11g：将用户表空间设为只读 →
expdp ... transport_tablespaces=TS1,TS2 version=12.1（必须指定version=12.1兼容19c） - 拷贝datafile + dump文件到目标Linux服务器
- 目标库19c：
impdp ... transport_datafiles='/u01/oradata/ts1.dbf' remap_schema=olduser:newuser
USERS表空间不能直接TTS迁移，需单独导出导入；SYSTEM/SYSAUX永远不可传输，元数据靠expdp/impdp补全。
最容易被忽略的三个实操细节
一是DB_FILE_NAME_CONVERT和LOG_FILE_NAME_CONVERT在跨平台DG中必须显式设置，且路径分隔符要匹配目标OS（Linux用/，Windows用\），漏配会导致duplicate失败或MRP进程卡住；二是逻辑DG切换前，务必在19c备库执行EXEC DBMS_LOGSTDBY.APPLY_SET('PREPARE_SWITCHOVER', TRUE)，否则角色切换会hang住；三是TTS迁移后，19c上必须手动重建统计信息（DBMS_STATS.GATHER_DICTIONARY_STATS），否则查询计划严重劣化——这点文档从不提，但线上真实发生过。
