Oracle DG环境应用CPU补丁且不影响同步的方法

先说几个核心判断：在Oracle DG环境中打补丁，顺序搞反了就是给自己找麻烦。记住，必须先升级备库，否则主库打完补丁后MRP进程会卡死或报ORA-00600——这不是配置上的疏忽，这是Oracle内核层面的不兼容。

为什么不能在主库先打CPU/PSU/RU？

Oracle 11.2.0.4+和19c/21c的CPU、PSU、RU补丁，会修改三类关键内部结构：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也救不回来

Oracle官方文档Doc ID 1265700.1明确禁止主库先行升级——这是硬性规定，不是建议。

备库必须处于MOUNT状态才能执行opatch auto

如果备库当前是OPEN READ ONLY（尤其是ADG场景），opatch auto会直接拒绝执行并报错。原因很简单：补丁安装过程需要修改$ORACLE_HOME下的二进制和SQL脚本，只读打开状态会锁定部分文件句柄，谁都不让你动。

正确的操作顺序是这样的：

1. 在主库执行ALTER SYSTEM SWITCH LOGFILE，确保最新归档已经传到备库
2. 备库执行SHUTDOWN IMMEDIATE，然后启动到MOUNT状态
3. 用root执行opatch auto /patch/path -oh $ORACLE_HOME——注意不是opatch apply
4. 完成后运行opatch lsinventory -detail | grep确认补丁编号已经注册
5. 重启备库至MOUNT，立即启动MRP：ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT

RAC环境升级时，OPatch版本和GI补丁必须同步

RAC节点上，如果opatch版本低于11.2.0.3.11（11g）或12.2.0.1.18（19c+），opatch auto会报error code 73，升级直接中断。更关键的是：GI补丁必须与DB补丁配套升级，否则datapatch阶段会失败，甚至引发OCR异常。

实操要点：

• 先检查所有节点的opatch version，不满足条件的统一升级OPatch
• GI补丁需要用opatch auto在root下单独应用，而且必须在DB补丁之前完成
• DB补丁升级后，必须在OPEN状态下对每个实例执行datapatch -verbose，这步不能跳过
• RAC滚动升级时，每次只升级一个节点，而且该节点必须完成datapatch并验证V$DATABASE中OPEN_MODE为READ WRITE后，再切到下一个

Switchover后原主库打补丁的三个硬约束

角色切换完成后，原主库变成新备库，这时候才能给它打补丁。但以下三点必须全部满足，否则同步立刻失效：

• $ORACLE_HOME路径、opatch lsinventory输出、补丁编号（包括子补丁）——甚至连空格和换行都必须与现主库逐行比对一致
• RAC环境下所有节点的OPatch版本必须≥要求的最低值，任何一个节点不达标都会导致opatch auto失败
• 绝对禁止在新备库上手动执行@?/rdbms/admin/catbundle.sql psu apply——这个脚本只应该在现主库执行，变更通过redo自动传播到备库

这里最容易被忽略的就是opatch lsinventory输出的细微差异——比如补丁描述末尾多了一个空格、时间戳格式不同，都可能让MRP解析失败。升级前务必用diff命令完整比对两台机器的输出，这个功夫省不得。