先说几个核心判断：在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脚本，只读打开状态会锁定部分文件句柄，谁都不让你动。
正确的操作顺序是这样的：
- 在主库执行
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命令完整比对两台机器的输出，这个功夫省不得。
