主库归档未发至备库，首要检查ARCH/LGWR传输模式匹配性及MRP进程状态，再定位归档缺口与I/O或SQL应用瓶颈。
检查 ARCH 和 LGWR 传输模式是否匹配主库配置
备库收不到归档，八成是主库没把日志真正发出去。先确认主库的 log_archive_dest_n 配置里用的是 sync/async 还是 arch 模式——arch 模式下，只有归档完成才触发传输，而 lgwr 是实时抓取在线日志，延迟更低但对网络更敏感。
- 查主库：
SELECT DESTINATION, TRANSMIT_MODE, AFFIRM, SYNC_LEVEL FROM V$ARCHIVE_DEST WHERE STATUS = 'VALID'; - 如果备库是物理 standby，推荐用
LGWR ASYNC；若用了ARCH却长期无新归档生成，得看主库ARCH进程是否卡住（V$ARCHIVE_PROCESSES中STATE是否为WAIT_FOR_LOG） -
AFFIRM=NO在异步模式下可降低主库等待，但备库写磁盘失败时可能丢日志；生产环境若启用了DELAY属性，也会人为制造 lag，记得检查DELAY_MINS值
确认 MRP 进程是否真实运行且未挂起
备库看起来在恢复，其实 MRP（Managed Recovery Process）可能早就停了。它不报错、不退出，只是静默暂停，比如遇到坏块、归档缺失或控制文件时间戳异常时会自动 halt。
- 查状态：
SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK# FROM V$MANAGED_STANDBY WHERE PROCESS IN ('MRP0', 'RFS');—— 如果STATUS是APPLYING_LOG才算真干活；WAIT_FOR_LOG或IDLE很可能是卡住了 - 常见诱因：归档文件名被手动改过（如加了后缀）、
DB_RECOVERY_FILE_DEST空间满、备库控制文件不是从主库ALTER DATABASE CREATE STANDBY CONTROLFILE生成的 - 重启 MRP 不等于
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;再启动——必须加USING CURRENT LOGFILE才能续上实时流，否则可能跳过未应用的 gap
定位 gap 并手工补全缺失归档
当 V$ARCHIVE_GAP 查出有 gap，说明 RFS 收到了部分日志，但中间断了几段。别急着从主库 scp 所有归档，先确认哪些真缺、哪些只是路径/权限问题。
- 查 gap：
SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;—— 注意它是按 thread 分的，RAC 环境要逐个 thread 看 - 去主库找对应归档：
LIST ARCHIVELOG FROM SEQUENCE <low_seq> UNTIL SEQUENCE <high_seq> THREAD <thread>;</thread></high_seq></low_seq>，再用COPY ARCHIVELOG或scp传到备库相同目录结构下（路径必须和LOG_ARCHIVE_DEST_2一致） - 传完别直接注册：先
ALTER DATABASE REGISTER PHYSICAL LOGFILE '<full_path_to_arch>'; </full_path_to_arch>，再RECOVER AUTOMATIC STANDBY DATABASE;—— 手动注册能绕过 RFS 的校验逻辑，避免因文件时间戳或大小微小差异被拒
识别 Apply Lag 的真实瓶颈是 I/O 还是 SQL 应用层
APPLY LAG 显示 2 小时，未必是网络慢。物理 standby 的 apply 实际分两步：RFS 写归档（I/O）、MRP 读+解压+应用（CPU + redo 解析）。得分开看。
- 查实时 lag：
SELECT ROUND((SYSDATE - FIRST_TIME)*24*60, 2) AS MINS_BEHIND FROM V$ARCHIVED_LOG WHERE SEQUENCE# = (SELECT MAX(SEQUENCE#) FROM V$ARCHIVED_LOG WHERE DEST_ID = 2) AND DEST_ID = 2;—— 这比V$DATAGUARD_STATS的apply lag更准，后者可能缓存旧值 - 如果
RFS的STATUS是IDLE但MRP的STATUS是APPLYING_LOG，说明日志已收全，瓶颈在 apply 阶段：开ALTER SESSION SET EVENTS '10046 trace name context forever, level 8';跟踪 MRP 进程，重点看db file sequential read和redo log space request等待 - 大事务（如分区交换、索引重建）在备库回放极慢，因为物理 standby 必须逐条重演 redo，没法并行跳过——这种 lag 是设计使然，不是故障，监控里看到 spike 别慌
最常被忽略的一点：备库开了 ADG（Active Data Guard）但没启用实时查询（ALTER DATABASE OPEN READ ONLY 后没加 ENABLE QUERY REWRITE），会导致 MRP 被阻塞在某些字典操作上；另外，_disable_log_archive_dump 这类隐藏参数若被误设，会让归档日志不落盘，RFS 根本无文件可收。
