如何配置Oracle Data Guard来支持跨平台异构操作系统容灾

Oracle 19c物理Data Guard不支持跨平台（如Linux主库到Windows备库），因重做日志依赖平台一致的字节序、块结构和二进制兼容性；唯一可行方案是逻辑standby，通过SQL Apply解析重做为DML/DDL重放，但要求字符集兼容、COMPATIBLE参数相同且需规避不支持的数据类型。

Oracle 19c 物理 Data Guard 不支持跨平台

直接配置 linux 主库到 windows 备库的物理 data guard 会失败，不是配置漏了，而是 oracle 内部机制根本禁止——重做日志（redo）是字节级块结构，依赖平台一致的 db_block_size、字节序（endianness）、内存布局和二进制兼容性。一旦平台 id 不同（比如 v$database.platform_id 返回 13 和 62），alter database recover managed standby database 就会报 ora-01172 或 ora-01151，本质是块解析崩溃，不是网络或权限问题。

跨平台唯一可行路径：逻辑 standby

逻辑 standby 通过 SQL Apply 解析 redo 为 DML/DDL，在目标库上重放，绕过了物理块限制。但它有硬约束：

• 主备库字符集必须兼容（如都用 AL32UTF8），否则 LOGSTDBY 进程启动即报 ORA-01285
• 不支持所有数据类型：比如 BFILE、ROWID 类型列、含函数索引的表，需提前用 DBMS_LOGSTDBY.CHECK_UPGRADE 扫描
• COMPATIBLE 参数必须相同（如都 ≥ 19.0.0），否则 ALTER DATABASE START LOGICAL STANDBY 直接拒绝
• 切换后，原主库需手动重建控制文件并重置日志序列，不能自动回切

可传输表空间（TTS）只适合计划性迁移，不是容灾

TTS 常被误当作跨平台 Data Guard 替代方案，但它本质是“冷搬”，不是持续同步：

• 必须停写源库，或至少在 DBMS_TTS.TRANSPORT_SET_CHECK 执行期间禁止 DDL，否则 transport_set_violations 视图报外键跨表空间等错误
• RMAN CONVERT TABLESPACE ... TO PLATFORM 'Linux x86 64-bit' 是必需步骤，AIX 或 Windows 源库无法跳过
• 目标库要提前建好相同名称的表空间，且 DB_FILES 参数需足够容纳新数据文件
• 整个流程 RPO 至少数小时，无法应对突发故障

别信“Windows 和 Linux 能配物理 DG”的旧文档

某些 2017 年左右的实操笔记声称用 RMAN Duplicate 成功配出跨平台物理 standby，那是在特定补丁集（如 11.2.0.4.161018）+ 禁用部分特性（如 ADG、RAC）下的偶然成功，Oracle 官方从未认证该组合。19c 及以后版本已明确移除对异构平台物理 standby 的任何隐式支持，DGMGRL 在检测到 platform_id 不匹配时会直接拒绝 ENABLE CONFIGURATION。

真正跨平台容灾，要么接受逻辑 standby 的功能折损，要么用 GoldenGate —— 但那是另一套许可和运维体系了。