oracle 19c及以后不支持跨平台物理data guard，因platform_id不匹配（如linux为13、windows为62）导致ora-01172/ora-01151错误，本质是重做日志块结构（字节序、块大小等）无法跨平台解析；唯一可行方案是逻辑standby，但需满足compatible参数一致、字符集兼容、且通过dbms_logstdby.check_upgrade排除不支持对象。
Oracle 19c 及以后版本不支持跨平台物理 Data Guard，强行配置会直接失败，不是参数没配对，而是 Oracle 内部校验 platform_id 不匹配时就拒绝启动恢复。
为什么 ALTER DATABASE RECOVER MANAGED STANDBY DATABASE 会报 ORA-01172 或 ORA-01151
这两个错误本质是重做日志块解析崩溃：Linux 主库生成的 redo 块（小端序、特定 db_block_size、内存对齐方式）在 Windows 备库上无法被物理层正确读取。Oracle 在启动 SQL Apply 或 Redo Apply 前，会比对 v$database.platform_id —— Linux x86_64 是 13，Windows x64 是 62，只要不等，DGMGRL ENABLE CONFIGURATION 就会静默拒绝，ALTER DATABASE START LOGICAL STANDBY 则会在后续步骤中卡住或报错。
- 不是网络不通、密码错、监听没起，而是平台 ID 硬性不兼容
-
ORA-01172常出现在尝试RECOVER时，表示控制文件里记录的 checkpoint block 与当前平台块结构不匹配 -
ORA-01151多见于备库STARTUP MOUNT后执行恢复前，Oracle 检测到数据文件头平台标识非法
唯一可行路径：逻辑 standby + 严格前置检查
逻辑 standby 绕过物理块限制，靠 LOGSTDBY 进程解析 redo 为 SQL 再执行，但它不是“万能胶”，必须满足三硬条件：
- 主备库
COMPATIBLE参数必须完全一致（如都设为19.0.0），否则ALTER DATABASE START LOGICAL STANDBY直接报错 - 字符集必须兼容：推荐两端都用
AL32UTF8；若主库是ZHS16GBK，备库必须同字符集，否则LOGSTDBY启动即报ORA-01285 - 运行
DBMS_LOGSTDBY.CHECK_UPGRADE扫描全库，提前暴露不支持对象（如含BFILE列的表、函数索引、ROWID类型列），这些表需排除在逻辑应用范围外或重构
别把可传输表空间（TTS）当 Data Guard 用
TTS 是冷迁移手段，和 Data Guard 的持续同步有本质区别：
- 必须停写源库，或至少在
DBMS_TTS.TRANSPORT_SET_CHECK执行期间禁止 DDL，否则transport_set_violations视图会报外键跨表空间等错误 -
RMAN CONVERT TABLESPACE ... TO PLATFORM 'Linux x86 64-bit'是强制步骤，Windows 源库不能跳过 - 目标库要提前建好同名表空间，且
DB_FILES参数必须足够容纳新数据文件数量 - RPO 至少数小时，无法应对突发故障——这不是容灾，是计划内迁移
真正跨平台容灾，得接受功能折损或换技术栈
逻辑 standby 虽可行，但代价明显：
- 切换后原主库不能自动回切，需手动重建控制文件、重置日志序列
- 不支持所有 DDL（如
ALTER DATABASE级操作）、部分数据类型、全局临时表 - 性能开销比物理 standby 高，SQL 解析和重放本身就有延迟累积风险
如果业务无法接受这些限制，Oracle GoldenGate 是更现实的选择：它工作在事务日志逻辑层，天然支持异构平台、跨版本、细粒度同步（可只同步某几个 schema），且 RPO 可控在秒级。Data Guard 的跨平台幻想，到 19c 已彻底关闭。
