Oracle 19c Data Guard升级补丁后不同步，主因是主备库补丁级别未对齐、VALID_FOR参数缺失STANDBY_ROLE、standby_file_management被重置为MANUAL，或旧归档校验失败导致MRP0静默挂起。
Oracle 19c Data Guard 升级补丁后不同步，大概率不是补丁本身“坏了”，而是补丁触发了原有配置的兼容性问题或状态不一致——比如主备库补丁级别不对齐、LOG_ARCHIVE_DEST_2中VALID_FOR失效、或standby_file_management在补丁重启后被重置为MANUAL。
补丁升级后主备库版本/补丁号不一致
19c 的 RU（Release Update）和 RUR（Release Update Revision）要求主备库必须严格对齐。哪怕主库打了 April 2026 RU，备库只打了 January 2026 RU，MRP0 就会静默挂起，不报错但不再推进 SEQUENCE#。
- 查主库：SELECT BANNER_FULL FROM V$VERSION;
- 查备库：同上，对比输出中 “Release” 和 “RU” 字段是否完全一致
- 特别注意：
OPATCH LSINVENTORY输出里Database Release Update行必须相同；仅Oracle Database 19c版本号一致不够 - 补丁不一致时，
v$dataguard_stats中apply_lag会持续增长，v$managed_standby中 MRP0 状态可能为IDLE或WAIT_FOR_LOG，但无明显错误日志
VALID_FOR 参数在补丁后失效导致传输中断
19c 某些 RU（如 19.21+）强化了 VALID_FOR 校验逻辑。如果主库是 RAC，且 LOG_ARCHIVE_DEST_2 中只写了 VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)，而没显式包含 STANDBY_ROLE，补丁升级后 RFS 进程可能拒绝接收日志，v$archive_gap 为空但同步停滞。
- 查主库当前配置：SHOW PARAMETER log_archive_dest_2
- 正确写法应为：
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)(STANDBY_LOGFILES,STANDBY_ROLE) - 若缺失
STANDBY_ROLE部分，执行：ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=stdb LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=stdb' SCOPE=BOTH; - 改完立刻查备库
v$managed_standby，确认RFS进程STATUS是否变为IDLE（表示已开始接收）
standby_file_management 被重置为 MANUAL
某些 19c 补丁（尤其是涉及 ASM 或 PDB 的 RUR）会在实例重启时将 standby_file_management 从 AUTO 重置为 MANUAL。一旦主库新增数据文件或 PDB，备库不会自动创建对应文件，MRP0 遇到 UNNAMED 文件就卡住，v$logstdby 或 v$managed_standby 不报错但 SEQUENCE# 冻结。
- 查备库当前值：
SHOW PARAMETER standby_file_management - 若返回
MANUAL，立即执行：ALTER SYSTEM SET standby_file_management = AUTO SCOPE=BOTH; - 然后检查
v$datafile，看是否存在UNNAMED文件名；有则需手动处理：ALTER DATABASE CREATE DATAFILE '/u01/app/oracle/product/19c/dbs/UNNAMED00026' AS '+DATADG1/ORCL/DATAFILE/users.256.123456789'; - 注意：路径必须与主库
v$datafile中对应文件的NAME字段完全一致（包括 ASM 别名），否则仍会失败
补丁后归档日志校验更严格，旧归档被拒收
19c 后期 RU 引入更严格的归档日志完整性校验。如果备库磁盘上有补丁前传来的归档（尤其经 scp 手动拷贝过），补丁升级后 MRP0 可能因校验失败直接跳过该日志，也不报 ORA 错误，只在 alert.log 末尾留一句 skipping archived log ... checksum mismatch。
- 查备库 alert.log 最后 50 行：
tail -50 $ORACLE_BASE/diag/rdbms/*/alert/*.log | grep -i "skip\|checksum" - 若发现跳过记录，用
LIST ARCHIVELOG确认缺口，再从主库重新传输对应归档（不要复用旧文件） - 传输后必须手动注册：
ALTER DATABASE REGISTER PHYSICAL LOGFILE '<code>full_path_to_arch';，绕过校验 - 别依赖
RECOVER AUTOMATIC—— 它默认跳过校验失败的日志，手动注册才能强制加载
补丁升级后的不同步，很少是单一原因；往往多个配置项同时“松动”，比如 VALID_FOR 失效导致 RFS 停收，叠加 standby_file_management 被重置，再遇上旧归档校验失败，三者叠加会让问题看起来像“完全卡死”。排查时别只盯一个点，优先跑一遍这四个检查项，顺序不能乱——先版本，再传输参数，再文件管理，最后归档校验。
