Oracle19c Data Guard升级补丁后为何不同步？

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#。

1. 查主库：SELECT BANNER_FULL FROM V$VERSION;
2. 查备库：同上，对比输出中 “Release” 和 “RU” 字段是否完全一致
3. 特别注意：OPATCH LSINVENTORY 输出里 Database Release Update 行必须相同；仅 Oracle Database 19c 版本号一致不够
4. 补丁不一致时，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 为空但同步停滞。

1. 查主库当前配置：SHOW PARAMETER log_archive_dest_2
2. 正确写法应为：VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)(STANDBY_LOGFILES,STANDBY_ROLE)
3. 若缺失 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;
4. 改完立刻查备库 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# 冻结。

1. 查备库当前值：SHOW PARAMETER standby_file_management
2. 若返回 MANUAL，立即执行：ALTER SYSTEM SET standby_file_management = AUTO SCOPE=BOTH;
3. 然后检查 v$datafile，看是否存在 UNNAMED 文件名；有则需手动处理：ALTER DATABASE CREATE DATAFILE '/u01/app/oracle/product/19c/dbs/UNNAMED00026' AS '+DATADG1/ORCL/DATAFILE/users.256.123456789';
4. 注意：路径必须与主库 v$datafile 中对应文件的 NAME 字段完全一致（包括 ASM 别名），否则仍会失败

补丁后归档日志校验更严格，旧归档被拒收

19c 后期 RU 引入更严格的归档日志完整性校验。如果备库磁盘上有补丁前传来的归档（尤其经 scp 手动拷贝过），补丁升级后 MRP0 可能因校验失败直接跳过该日志，也不报 ORA 错误，只在 alert.log 末尾留一句 skipping archived log ... checksum mismatch。

1. 查备库 alert.log 最后 50 行：tail -50 $ORACLE_BASE/diag/rdbms/*/alert/*.log | grep -i "skip|checksum"
2. 若发现跳过记录，用 LIST ARCHIVELOG 确认缺口，再从主库重新传输对应归档（不要复用旧文件）
3. 传输后必须手动注册：ALTER DATABASE REGISTER PHYSICAL LOGFILE 'full_path_to_arch';，绕过校验
4. 别依赖 RECOVER AUTOMATIC —— 它默认跳过校验失败的日志，手动注册才能强制加载

补丁升级后的不同步，很少是单一原因；往往多个配置项同时“松动”，比如 VALID_FOR 失效导致 RFS 停收，叠加 standby_file_management 被重置，再遇上旧归档校验失败，三者叠加会让问题看起来像“完全卡死”。排查时别只盯一个点，优先跑一遍这四个检查项，顺序不能乱——先版本，再传输参数，再文件管理，最后归档校验。