在OracleDG环境中必须先升级备库,否则主库打补丁会导致MRP进程报错中断。正确顺序:主库切换日志,备库mount后执行opatchauto,重启MRP。RAC需同步OPatch版本和GI补丁。Switchover后原主库打补丁需逐行比对补丁信息,避免同步失效。
先说几个核心判断:在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]ALTER DATABASE RECOVER也救不回来Oracle官方文档Doc ID 1265700.1明确禁止主库先行升级——这是硬性规定,不是建议。
备库必须处于MOUNT状态才能执行opatch auto
如果备库当前是OPEN READ ONLY(尤其是ADG场景),opatch auto会直接拒绝执行并报错。原因很简单:补丁安装过程需要修改$ORACLE_HOME下的二进制和SQL脚本,只读打开状态会锁定部分文件句柄,谁都不让你动。
正确的操作顺序是这样的:
ALTER SYSTEM SWITCH LOGFILE,确保最新归档已经传到备库SHUTDOWN IMMEDIATE,然后启动到MOUNT状态root执行opatch auto /patch/path -oh $ORACLE_HOME——注意不是opatch applyopatch lsinventory -detail | grep确认补丁编号已经注册MOUNT,立即启动MRP:ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECTRAC环境升级时,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,不满足条件的统一升级OPatchopatch auto在root下单独应用,而且必须在DB补丁之前完成datapatch -verbose,这步不能跳过datapatch并验证V$DATABASE中OPEN_MODE为READ WRITE后,再切到下一个Switchover后原主库打补丁的三个硬约束
角色切换完成后,原主库变成新备库,这时候才能给它打补丁。但以下三点必须全部满足,否则同步立刻失效:
$ORACLE_HOME路径、opatch lsinventory输出、补丁编号(包括子补丁)——甚至连空格和换行都必须与现主库逐行比对一致OPatch版本必须≥要求的最低值,任何一个节点不达标都会导致opatch auto失败@/rdbms/admin/catbundle.sql psu apply——这个脚本只应该在现主库执行,变更通过redo自动传播到备库这里最容易被忽略的就是opatch lsinventory输出的细微差异——比如补丁描述末尾多了一个空格、时间戳格式不同,都可能让MRP解析失败。升级前务必用diff命令完整比对两台机器的输出,这个功夫省不得。
侠游戏发布此文仅为了传递信息,不代表侠游戏网站认同其观点或证实其描述