必须先升级备库，否则主库打完补丁后MRP进程会卡死或报ORA-00600；因PSU修改数据字典、版本号及元数据，旧备库无法解析新归档日志，导致ADG同步中断，官方明确不支持主库先行升级。
必须先升级备库，否则主库打完补丁后，备库mrp进程会直接卡死或报ora-00600，同步彻底中断。
为什么不能在主库先打PSU/Bundle Patch
Oracle 11g（11.2.0.4+）的PSU/Bundle Patch会修改数据字典结构、DBA_REGISTRY_HISTORY中的版本号，以及内部对象元数据。主库升级后生成的归档日志包含新版本SCN和DDL元数据，而旧版备库无法解析——典型表现为：MRP进程状态长期停留在APPLYING_LOG但无实际推进，或报ORA-00600: internal error code, arguments: [kcvxfResync]。此时SELECT MAX(SEQUENCE#) FROM V$ARCHIVED_LOG WHERE APPLIED='YES'不再增长，ADG已失效。
这不是配置问题，是Oracle内核级不兼容。官方文档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补丁编号 - 重启备库到
MOUNT后，立即启动MRP：ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT；验证V$MANAGED_STANDBY中MRP进程状态为APPLYING_LOG且归档应用序列号持续递增
Switchover后原主库升级的关键限制
切换角色后，原主库成为新备库，此时才能对其打补丁。但注意三个硬性约束：
-
$ORACLE_HOME路径、版本号、补丁集必须与已升级的备库（现主库）完全一致，opatch lsinventory输出需逐行比对 - RAC环境下，所有节点的
OPatch版本必须≥11.2.0.3.11，否则opatch auto报错error code 73 - 切勿在新备库上手动执行
@?/rdbms/admin/catbundle.sql psu apply——该脚本只应在主库（即刚升级成功的那台）执行，通过redo自动传播到新备库
最容易被忽略的兼容性细节
很多人以为只要数据库版本一致就安全，其实还有三处隐性依赖极易出问题：
-
/etc/hosts中主备主机名解析必须双向可达，尤其DG Broker场景下，DGMGRL连接失败会导致switchover卡在WAITING FOR GAP - 备库升级前未清空
$ORACLE_HOME/cfgtoollogs/opatch目录，残留旧日志可能干扰opatch auto判断补丁状态 - 使用
opatch auto时未指定-ocmrf参数，导致静默模式下缺少OCM响应文件，补丁安装中途挂起但无报错提示
