oracle 19c起官方禁止windows与linux间搭建物理data guard，因platform_id校验（linux=13，windows=62）直接拒绝redo应用；逻辑standby是唯一支持方案，但需compatible一致、字符集兼容且通过check_upgrade验证。
Oracle 19c 及以后版本，Windows 与 Linux 之间无法搭建物理 Data Guard —— 不是配置不对，而是 Oracle 内部机制明确禁止。
ORA-01172 和 ORA-01151 是跨平台物理 DG 的“判决书”
当你在 Linux 主库上执行 alter database recover managed standby database，而备库是 Windows，几乎必然报 ORA-01172（recovery中断）或 ORA-01151（需要介质恢复但找不到对应文件）。这不是路径写错、监听不通或密码文件缺失，而是 Oracle 在底层校验 v$database.platform_id 时直接拒绝：Linux 平台 ID 是 13，Windows 是 62，二者不匹配，RFS 进程根本不会尝试解析传来的 redo 块。
常见误判点：
- 以为 RMAN Duplicate 成功就代表可行——那只是 11g 某些补丁集下的临时绕过，19c 已移除所有隐式支持
- 把
DGMGRL ENABLE CONFIGURATION报错当成网络问题，其实它在连接前就查 platform_id 并提前终止 - 手动拷贝控制文件 + 数据文件后启动备库，会卡在
ORACLE_HOME/dbs下找不到orapw<code> 文件，但即使补上，MRP 启动即崩溃</code>
逻辑 Standby 是唯一官方支持的跨平台方案
逻辑 Standby 绕过物理块限制，靠 LOGSTDBY 进程将 redo 解析为 SQL 再执行。但它不是“开箱即用”，必须满足硬性前提：
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
-
COMPATIBLE参数主备必须完全一致（如都设为19.0.0），否则ALTER DATABASE START LOGICAL STANDBY直接报错 - 字符集必须兼容：主库
NLS_CHARACTERSET和备库NLS_NCHAR_CHARACTERSET都需是AL32UTF8等通用编码，否则LOGSTDBY启动即抛ORA-01285 - 需提前运行
DBMS_LOGSTDBY.CHECK_UPGRADE扫描不支持对象：含BFILE、ROWID列、函数索引、物化视图日志的表会被跳过或报错 - 切换后原主库不能自动回切，必须手动重建控制文件、重置日志序列，且需停业务窗口
RMAN Active Duplicate 在 11g 是历史特例，别在 19c 上试
Doc ID 881421.1 提到的 DUPLICATE TARGET DATABASE FOR STANDBY FROM ACTIVE DATABASE 跨平台操作，仅适用于 11.1.0.6–11.2.0.4 的特定补丁组合，并依赖禁用 ADG、RAC、SecureFiles 等特性。2026 年的 19c 环境中：
-
RMAN在检测到源平台和目标平台不同时，会直接报ORA-19554（device allocation failed）并中止 - 即使强行用
CONVERT DATABASE转换数据文件，也无法转换 control file 和 redo log 结构，备库无法识别自身角色 - 所谓“成功启动”的案例，实际是备库处于
NOMOUNT或MOUNT状态下未触发 MRP，一旦开启应用，立刻失败
真正要落地，得接受功能折损或换技术栈
逻辑 Standby 的限制很实在：不能建新索引、不能加约束、DML 冲突需人工干预、全局临时表不复制。如果你的业务依赖这些，或者要求零 RPO/RTO，那就得面对现实：
- GoldenGate 是跨平台持续同步的工业级选择，但它独立于 Oracle 许可体系，需额外采购和运维
- 可传输表空间（TTS）只适合计划内迁移，
RMAN CONVERT TABLESPACE ... TO PLATFORM是强制步骤，且整个过程 RPO 至少数小时，不是容灾方案 - 别信“改 registry 或打隐藏 patch 就能跑通物理 DG”的说法——19c 的 platform_id 校验已下沉至 kernel 层，绕过等于破坏一致性
跨平台容灾没有银弹。逻辑 Standby 的配置复杂度、对象兼容性检查、切换后的验证成本，远高于同平台物理 DG。动手前，先跑通 DBMS_LOGSTDBY.CHECK_UPGRADE 输出，再决定要不要继续。
