oracle data guard自动追平依赖归档传输链路断点续传而非fal重试；需查v$managed_standby中mrp0状态、v$archive_gap及v$archive_dest_status确认真实进度；reopen参数调控arch进程重推间隔，非fal行为；自动修复gap须满足主库归档未覆盖、备库控制文件完好、时间偏差合规等全部条件。
FAL进程不重试，靠的是归档传输链路的自动补发机制
Oracle Data Guard在网络闪断后能自动追平，根本不是FAL进程“主动重连”或“重传”，而是整个归档传输与应用链路具备状态感知和断点续传能力。只要主库归档日志没被覆盖、备库控制文件里记录的接收序列号没丢，网络恢复后，ARCH或LGWR进程会自动从上次中断处继续推送，MRP0进程也会自动从缺失位置开始应用——前提是Gap未发展成UNRESOLVABLE GAP。
怎么确认DG正在自动追平而不是卡死
闪断恢复后不能只看DG_BROKER状态为SUCCESS就以为万事大吉。真实同步进度得查底层视图：
- 在备库执行
SELECT process, status, sequence#, thread# FROM V$MANAGED_STANDBY;，重点看MRP0状态：如果是APPLYING_LOG且sequence#在持续递增，说明正在追；如果是WAIT_FOR_GAP，说明有归档没收到，得查Gap - 查
V$ARCHIVE_GAP：有返回值就代表存在明确缺失区间，此时MRP0不会自己跳过，必须人工干预或等主库重传 - 查
V$ARCHIVE_DEST_STATUS中dest_id=2（通常为主库到备库的归档目标）的error字段：若仍为ORA-12170或ORA-03113，说明底层连接还没通，不是DG的问题，是网络或监听层卡住了
REOPEN参数决定“重试节奏”，但不是越小越好
REOPEN是LOG_ARCHIVE_DEST_n里的关键参数，它控制归档传输失败后的等待间隔，直接影响自动追平的响应速度：
-
REOPEN=60：传输失败后等60秒再试一次；设太小（如REOPEN=5）会导致频繁建连冲击主库监听器，尤其在DNS不稳定时容易触发ORA-12535 - 它不作用于FAL本身，而是影响
ARCH进程推送归档的行为；FAL只是“拉”，而ARCH才是“推”的主力 - 如果主库用
SYNC模式，REOPEN对实时性影响有限，因为事务提交强依赖网络；但ASYNC下它就是追平延迟的调节阀
Gap出现后不手动干预也能自动修复的边界条件
自动修复只在满足全部以下条件时才发生，缺一不可：
- 主库归档日志还在：
V$ARCHIVED_LOG里能查到V$ARCHIVE_GAP中提示的LOW_SEQUENCE#到HIGH_SEQUENCE#所有记录，且DELETED='NO' - 备库控制文件未损坏：
SELECT current_scn FROM v$database;能正常返回，且V$STANDBY_LOG状态正常 - 主备库时间偏差SYSDATE比对出错，可能误判日志过期
- 没有启用
DELAY应用：如果配置了DELAY 30 MINUTE，即使日志已传全，MRP0也会强制卡住30分钟才开始应用
真正容易被忽略的是归档日志的保留策略——很多环境用RMANDELETE ARCHIVELOG UNTIL TIME清理，却忘了备库Gap还没填上。一旦主库把那段日志删了，自动追平就彻底失效，只能走增量备份重建。所以V$ARCHIVE_GAP不是查一次就完事，得配合监控告警盯住它的存在时长。
