不能在Oracle 11g中通过Data Guard搭建跨版本的容灾方案，主备库必须使用完全相同的小版本号（如11.2.0.4）及补丁集，否则启动备库会报ORA-01092或ORA-00704，MRP进程无法启动，DGMGRL连接后立即断开并报ORA-12547。
不能在oracle 11g中通过data guard搭建跨版本的容灾方案。主库与备库必须使用完全相同的小版本号（如 11.2.0.4），否则启动备库时会报 ora-01092 或 ora-00704，且日志应用（mrp）进程无法启动，broker连接直接失败。
ORA-01092：备库实例强制终止的典型表现
这个错误常出现在主库是 11.2.0.3、备库是 11.2.0.4（或反过来）时：
- 启动备库到
MOUNT状态看似成功，但执行ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT后几秒内实例崩溃； - alert.log 中紧随其后出现：
ORA-01092: ORACLE instance terminated. Disconnection forced； - 跟踪文件（trace file）里通常包含类似
incompatible database version或control file version mismatch的提示。
根本原因在于：
Oracle Data Guard 的物理备库依赖二进制级重放（block-level redo apply），而不同小版本之间 control file 结构、redo record 格式、甚至 SCN 处理逻辑可能存在不兼容变更 —— 这不是参数或配置能绕过的。
DGMGRL 连接后立即断开或报 ORA-12547
当你试图用 dgmgrl 连接跨版本备库时：
- 即使
tnsnames.ora和监听都配置正确，CONNECT sys/password@standby AS SYSDBA可能短暂成功，但执行SHOW CONFIGURATION就报错； - 常见错误是
ORA-12547: TNS:lost contact，而非网络超时类错误； - 这是因为 Broker 的后台代理进程（
DMON）尝试读取备库控制文件元数据时，发现版本签名不匹配，主动终止会话。
注意：
不要尝试从 12c 复制 dgmgrl 到 11g 环境，也不要把 11g 的密码文件拷到 12c 备库 —— 二进制不兼容会导致更隐蔽的静默失败（比如日志传输看似正常，但实际未写入 standby redo log）。
主备库小版本号必须严格一致的验证方式
别只看 SELECT * FROM v$version 输出的 “11.2.0.x” 表面一致：
- 执行：
SELECT banner FROM v$version WHERE banner LIKE 'Oracle%';
确保两库输出完全相同，包括末尾补丁信息（例如11.2.0.4.0vs11.2.0.4.190115）； - 检查 OPatch 版本：
$ORACLE_HOME/OPatch/opatch lsinventory -detail，确认关键组件（如 RDBMS、Network）补丁集一致； - 若主库打过 PSU（如
11.2.0.4.190115），备库必须安装完全相同的 PSU，不能只装 base release。
最稳妥的做法：
用 runInstaller -applyOneOffs 或 opatch apply 在备库上复现主库所有已应用的 one-off patch，再核对 opatch lsinventory 输出是否逐行一致。
跨版本容灾的唯一可行路径是升级到同一版本后再建 Data Guard，或者改用逻辑备库（LOGICAL STANDBY）——但 11g 中逻辑备库不支持所有数据类型（如 XMLType、SecureFile LOB），且 DDL 同步限制多，运维复杂度陡增。物理备库的版本锁定，是 Oracle 在一致性与性能间做的硬性取舍。
