主备库归档差异需关注单位时间序列连续性与blocks分布，applied='no'且sequence#连续缺失超5～10个、first_time间隔秒级、blocks异常偏小时须立即干预。
主备库归档生成量差异本身不是问题，但持续显著不一致往往暴露传输中断、应用卡死或配置错位——不能只比总量，得看单位时间内的序列连续性与 BLOCKS 分布。
查 v$archived_log 的 APPLIED 状态和 FIRST_TIME 密度
APPLIED='YES' 只表示 MRP 进程读过该归档，并不等于已写入数据文件。真正危险的信号是：大量 APPLIED='NO' 记录集中在极短时间窗口（FIRST_TIME 间隔秒级），且 SEQUENCE# 连续缺失。
- 必须加时间过滤，否则全表扫描慢且干扰大：
SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME, BLOCKS, APPLIED FROM v$archived_log WHERE FIRST_TIME > SYSDATE - 1/24 ORDER BY SEQUENCE# - 盯住 APPLIED = 'NO' 的连续段长度：超过 5～10 个就需干预；若 BLOCKS 异常偏小（如
- 别只扫最后几行——积压常藏在中间：SEQUENCE# 跳变（如从 1000 直接跳到 1005）、或停滞不动，才是真实滞后
比对主备 v$log_history 的 MAX(SEQUENCE#)
主库 v$log_history 的 MAX(SEQUENCE#) 是它已切换出的归档总数；备库同字段反映它“理论上能收到”的上限。差值 ≠ 同步延迟，但它是第一层粗筛指标。
- 主库执行：
SELECT MAX(SEQUENCE#) FROM v$log_history - 备库执行相同语句，再对比：差值 ≤ 2 属正常抖动；差值 ≥ 5 就得立刻进
v$archive_gap查缺口 - 若备库差值为 0，说明 RFS 进程根本没收到任何归档，问题在传输链路（主库
LOG_ARCHIVE_DEST_2配置错误、TNS 解析失败、监听未响应等）
看 v$managed_standby 中 MRP0 的实时推进状态
v$managed_standby 显示 PROCESS = 'MRP0' 不等于它在干活。常见静默卡死是 STATUS = 'APPLYING_LOG' 但 SEQUENCE# 几分钟不动，或反复卡在同一值上。
- 必须连查两次，间隔至少 10 秒：
SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK#, CLIENT_PROCESS FROM v$managed_standby WHERE PROCESS = 'MRP0' - 若 SEQUENCE# 不变、BLOCK# 停滞，立刻查备库
alert.log，搜ORA-01555、undo 不足、块损坏等线索 - 若根本查不到 MRP0 行，说明恢复没启用，需先
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL（防残留锁），再执行USING CURRENT LOGFILE DISCONNECT
RMAN 归档删除策略误判导致“假不同步”
Oracle 11g RAC 主库若用默认的 APPLIED ON ALL STANDBY 策略，在 ADG 场景下极易误删归档——因为备库处于 READ ONLY WITH APPLY 状态时，“APPLIED”语义不成立，RMAN 会提前清理尚未传完的归档。
- 正确策略必须是：
CONFIGURE ARCHIVELOG DELETION POLICY TO SHIPPED TO ALL STANDBY - 验证是否生效：
SHOW ARCHIVELOG DELETION POLICY输出应为SHIPPED TO ALL STANDBY - 该配置对 RAC 所有实例生效（
sid='*'），无需逐节点执行；但若之前设错，旧归档可能已被删，此时主库已无日志可传，备库自然“跟不上”
最易被忽略的是：归档生成量差异本身不报警，但 BLOCKS 偏小 + FIRST_TIME 密集 + APPLIED='NO' 连续出现，三者叠加才是重做流积压的指纹。监控脚本里漏掉任意一个维度，都可能把严重问题当成“暂时延迟”。
