主备库小版本号不一致时，Data Guard物理同步必然失败；必须确保主备库小版本号（如11.2.0.4.0）及PSU补丁完全一致，否则MRP0进程无法持续运行，需重搭备库。
主备库小版本号不一致时，Data Guard物理同步必然失败
oracle 11g中，主库与备库必须使用完全相同的小版本号（如11.2.0.4.0）和补丁集，否则物理data guard无法启动或运行。这不是配置能绕过的限制，而是二进制级兼容性问题——控制文件结构、redo record格式、scn处理逻辑在不同小版本间存在不可逆差异。
典型现象包括：ORA-01092（实例强制终止）、ORA-00704（引导进程失败）、MRP0进程启动后几秒内崩溃、DGMGRL连接后立即报ORA-12547并断开。
- 不要只比对
v$version输出的“11.2.0.4”，要执行SELECT banner FROM v$version WHERE banner LIKE 'Oracle%'确认末尾补丁信息完全一致（例如11.2.0.4.190115vs11.2.0.4.0） - 检查
$ORACLE_HOME/OPatch/opatch lsinventory -detail，确保RDBMS和Network组件补丁集一致 - 若主库打了PSU，备库必须安装**完全相同的PSU包**，不能仅装base release
误配跨版本后，MRP进程无法启动的直接验证方式
即使备库能STARTUP MOUNT成功，也不代表Data Guard就绪。真正关键的是MRP0是否持续处于APPLYING_LOG状态。
执行SELECT process, status, sequence# FROM v$managed_standby WHERE process = 'MRP0'，如果返回空行或status为WAIT_FOR_LOG/NOT ACTIVE，说明MRP已静默退出——这往往就是版本不匹配的直接后果，而非归档缺失或网络问题。
- 别依赖
ps aux | grep mrp，该命令可能显示进程残留，但内部早已halt - 立刻查看备库
alert.log最后100行，搜索ORA-01092或incompatible database version - 跟踪文件（trace file）里常出现
control file version mismatch提示，这是最明确的版本冲突证据
想升级又保持同步？唯一可行路径是转逻辑Data Guard
物理DG跨版本不可行，但逻辑DG（SQL Apply）可以。前提是主库必须提前完成三件事：执行DBMS_LOGSTDBY.BUILD、开启主键补充日志、清理不兼容对象。
不做这些准备，强行启用逻辑DG会立刻报错，比如ORA-16108（字典构建失败）或同步过程中丢失DML（因缺主键列日志）。
-
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS——不是ADD SUPPLEMENTAL LOG DATA，后者不够 - 查
DBA_LOGSTDBY_UNSUPPORTED和DBA_LOGSTDBY_NOT_UNIQUE，重点处理含LONG、ROWID列或无主键的表 - 升级备库前必须先停
SQL Apply：ALTER DATABASE STOP LOGICAL STANDBY APPLY，否则autoupgrade会与日志应用争抢数据字典锁
跨版本误操作后，恢复的底线是重搭物理备库
一旦发现版本不一致且MRP已崩溃，不要尝试用RECOVER DATABASE或增量备份修复——底层块结构不兼容，任何基于物理层的操作都无效。
正确做法是：停掉备库，用主库当前状态重建一个全新备库。这意味着你需要重新传输控制文件、全量备份、归档日志，并严格保证新备库的$ORACLE_HOME与主库小版本及补丁完全一致。
这个过程没有捷径。所谓“打个补丁让11.2.0.3识别11.2.0.4的redo”在Oracle官方支持矩阵里不存在，所有绕过版本校验的hack都会导致静默数据损坏。
