必须先升级备库，否则主库打完补丁后mrp进程会卡死或报ora-00600；因补丁修改dba_registry_history版本号、数据字典定义及元数据格式，旧备库无法解析新归档日志，导致adg同步中断，oracle官方doc id 1265700.1明确禁止主库先行升级。
必须先升级备库，否则主库打完补丁后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脚本，而只读打开状态会锁定部分文件句柄。
正确操作顺序是：
• 在主库执行ALTER SYSTEM SWITCH LOGFILE，确保最新归档已传到备库
• 备库执行SHUTDOWN IMMEDIATE → 启动到MOUNT状态
• 用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
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比对两台机器的完整输出。
