必须先升级备库，否则主库打完补丁后mrp进程会卡死或报ora-00600；因psu修改dba_registry_history版本号、数据字典及对象元数据，旧备库无法解析新归档日志，导致adg同步中断，官方doc id 1265700.1明确禁止主库先行升级。
必须先升级备库，否则主库打完补丁后 mrp 进程会卡死或报 ora-00600；这不是配置疏漏，而是 oracle 内核级不兼容——旧备库根本无法解析新归档日志里的元数据变更。
为什么不能在主库先打 PSU/Bundle Patch
Oracle 11.2.0.4+ 的 PSU 补丁会修改三类关键内部结构：DBA_REGISTRY_HISTORY 中的版本号、数据字典表定义、以及对象元数据（如 OBJ$、COL$ 的内部格式）。主库升级后生成的归档日志携带新 SCN 和 DDL 元数据，而未升级的备库在 MRP 应用时会直接失败。
典型现象包括：
-
V$MANAGED_STANDBY中 MRP 进程状态长期显示为APPLYING_LOG，但SELECT MAX(SEQUENCE#) FROM V$ARCHIVED_LOG WHERE APPLIED='YES'不再递增 - 日志中反复出现
ORA-00600: internal error code, arguments: [kcvxfResync] - ADG 同步彻底中断，且无法通过
ALTER DATABASE RECOVER...恢复
官方文档 Doc ID 1265700.1 明确禁止“主库先行升级”模式，这不是建议，是硬性限制。
Standby-First Patching 四步实操要点
以单实例 11.2.0.4 + PSU 11.2.0.4.20 为例（RAC 需额外处理 GI 补丁）：
- 停同步前，在主库执行
ALTER SYSTEM SWITCH LOGFILE，确保最新归档已传至备库 - 备库必须处于
MOUNT状态（非OPEN READ ONLY），否则opatch auto会拒绝执行 - 用
root执行opatch auto /patch/path -oh $ORACLE_HOME（不是opatch apply）；完成后运行opatch lsinventory -detail | grep 11.2.0.4.20确认补丁已注册 - 重启备库到
MOUNT后，立即启动 MRP：ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT；验证V$MANAGED_STANDBY中进程状态和归档序列号是否持续推进
Switchover 后原主库升级的三个硬约束
角色切换完成后，原主库成为新备库，此时才能对其打补丁。但以下三点必须全部满足，否则同步将失败：
-
$ORACLE_HOME路径、版本号、补丁集必须与现主库（即刚升级成功的那台）完全一致，opatch lsinventory输出需逐行比对，连空格都不能差 - RAC 环境下，所有节点的 OPatch 版本必须 ≥
11.2.0.3.11，否则opatch auto报错error code 73 - 切勿在新备库上手动执行
@?/rdbms/admin/catbundle.sql psu apply——该脚本只应在现主库执行，由 redo 自动传播变更
最容易被忽略的兼容性细节
很多人以为只要 SELECT * FROM v$version 显示版本一致就安全，其实还有三处隐性依赖极易出问题：
-
/etc/hosts中主备主机名必须双向解析可达，尤其 DG Broker 场景下，DGMGRL连接失败会导致switchover卡在WAITING FOR - 主备库的
compatible参数值必须相同（如都设为11.2.0），否则逻辑层元数据校验通不过 - 备库
log_archive_dest_2的VALID_FOR属性若仍指向旧主库 SERVICE_NAME，switchover 后可能无法自动重连
这些点不报错、不告警，但会在 switchover 关键时刻突然阻塞，而且排查路径极深。
