不能并行升级，因PSU/RU修改redo格式与SCN逻辑，主库升级后生成新格式redo，备库旧版本无法解析，导致同步中断、ORA-1054或ORA-600错误。
必须先停主库日志传输、再分步打补丁，Primary和Standby不能同时在线升级，否则会因redo不兼容导致同步中断甚至ORA-1054错误。
为什么不能直接在运行中的Data Guard上并行打PSU/RU
Oracle 19c的PSU（Patch Set Update）和RU（Release Update）本质是二进制级变更，会影响redo生成与应用逻辑。物理备库的Redo Apply进程依赖主库生成的redo流结构，而补丁可能修改redo record格式、SCN处理方式或归档日志头校验逻辑。一旦Primary打完补丁重启，开始生成新格式redo，但Standby仍运行旧版本软件，就会在apply时卡住或报ORA-1054、ORA-600 [krsb_rkb_get_next_log_2]等内部错误。
常见误操作包括：只给Primary打补丁、Standby跳过补丁、或两个节点用不同OPatch版本解压同一补丁包。
- PSU/RU不是纯SQL层更新，它修改
$ORACLE_HOME/rdbms/lib下的核心链接库和$ORACLE_HOME/rdbms/admin下的字典脚本 - Standby即使处于
MOUNT状态，只要启动了MRP（Managed Recovery Process），就会尝试解析新redo —— 此时若软件未同步升级，解析必然失败 - RAC环境还需额外注意grid用户和oracle用户的OPatch版本必须一致，否则
opatch apply会静默跳过部分组件
Standby必须先停MRP并升到MOUNT状态再打补丁
这是最容易被跳过的强制步骤。Standby不需要运行@catbundle.sql，但必须升级其Oracle软件（$ORACLE_HOME），否则无法识别Primary发来的已升级redo。
实操要点：
- 在Standby执行：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;，确认V$MANAGED_STANDBY中MRP进程已消失 - 关闭数据库：
SHUTDOWN IMMEDIATE；关闭监听：lsnrctl stop；如有ASM，也需停掉crsctl stop res ora.asm - 升级OPatch（如需）：
unzip -q p6880880_190000_Linux-x86-64.zip -d $ORACLE_HOME，然后验证$ORACLE_HOME/OPatch/opatch version≥ 12.2.0.1.19 - 应用补丁：
$ORACLE_HOME/OPatch/opatch apply（仅对软件目录，不涉及数据库实例） - 启动到MOUNT：
STARTUP MOUNT；不要执行ALTER DATABASE RECOVER...，也不要打开数据库
Primary打补丁必须包含软件+数据库字典两步
Primary不仅要升级$ORACLE_HOME，还必须运行catbundle.sql更新数据字典视图和内部对象。漏掉这步会导致后续DBA_REGISTRY_SQLPATCH记录不全，且某些PSU修复的PL/SQL包（如DBMS_STATS）不会生效。
关键命令顺序不可颠倒：
- 停Primary日志传输：
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_n=DEFER SCOPE=BOTH;（n为实际指向Standby的dest编号） - 关闭Primary所有实例、监听、ASM（RAC需逐节点操作）
- 用oracle用户升级OPatch并
opatch apply补丁包 - 启动数据库到OPEN状态后，立即执行：
@$ORACLE_HOME/rdbms/admin/catbundle.sql psu apply（RU则用ru apply） - 执行完成后必须重启一次数据库，使字典变更完全加载
注意：catbundle.sql输出中若出现ERROR at line 1:或PL/SQL procedure successfully completed.之后还有大量ORA-04043，说明补丁未正确解压或权限不对 —— 检查$ORACLE_HOME/rdbms/admin下是否存在catbundle_PSU_文件。
补丁后验证必须检查v$archive_dest和dba_registry_sqlpatch
很多人只查opatch lsinventory就认为成功，但Data Guard场景下真正关键的是日志传输是否恢复、备库能否继续apply、以及字典补丁是否注册。
必须逐项确认：
- Primary上：
SELECT STATUS, ERROR FROM V$ARCHIVE_DEST WHERE DEST_ID = n;应返回VALID，且ERROR为空 - Standby上：
SELECT PROCESS, STATUS, THREAD#, SEQUENCE# FROM V$MANAGED_STANDBY;中MRP进程状态应为APPLYING_LOG，且SEQUENCE#持续递增 - 两边都查：
SELECT PATCH_ID, ACTION, STATUS FROM DBA_REGISTRY_SQLPATCH ORDER BY BUNDLE_SERIES DESC;确保Primary和Standby返回完全相同的PATCH_ID列表（Standby无字典补丁，但RU/PSU的SQL patch会通过redo自动同步） - 最后跑一次
SELECT * FROM V$DATABASE_INCARNATION;，确保主备当前incarnation相同 —— 若不同，说明某边resetlogs过，需重建Standby
最隐蔽的坑是：补丁安装成功、日志传输恢复、MRP也running，但某张系统表（如WRI$_OPTSTAT_HISTHEAD_HISTORY）因PSU新增字段导致统计信息收集失败，表现为DBMS_STATS.GATHER_DATABASE_STATS卡住。这种问题只能靠DBA_REGISTRY_SQLPATCH比对和alert.log里搜ORA-定位。
