先查备库v$archive_gap确认断层序列，再在主库v$archived_log中查询对应序列是否返回空；若为空且alert.log报ora-00308等错误，即可确认归档丢失导致gap。
主库删了归档，备库立刻报错——这不是传输中断那么简单，而是备库在尝试应用一个根本不存在的归档文件，典型表现为 ORA-01605、ORA-00308 或 FAL[client]: Failed to request gap sequence。必须先确认归档是否真丢失、Gap 是否已形成，再决定走 FAL 自动拉取还是 RMAN 增量修复。
怎么确认是归档丢失导致的 Gap
别急着重建或重传，先定位问题范围：
- 在备库查
V$ARCHIVE_GAP：有记录就说明存在明确的序列号断层，比如THREAD# = 1, LOW_SEQUENCE# = 1234, HIGH_SEQUENCE# = 1237 - 在主库查
V$ARCHIVED_LOG对应序列号：执行SELECT NAME, FIRST_TIME, NEXT_TIME FROM V$ARCHIVED_LOG WHERE THREAD# = 1 AND SEQUENCE# BETWEEN 1234 AND 1237;—— 若返回空，确认归档已被删除 - 看备库 alert.log 最近几行：重点找
MRP0: Background Managed Standby Recovery process started后紧跟着的ORA-00308或ORA-19505，错误路径里会带出缺失的归档名（如1_1235_947274260.dbf）
归档还在主库？优先启用 FAL 自动补全
如果主库上那些“缺失”的归档其实没被删，只是没传过去（比如归档目标被 DEFER 或网络抖动），FAL 是最轻量的解法，无需人工干预文件传输：
- 检查主库
LOG_ARCHIVE_DEST_2的FAL_SERVER和FAL_CLIENT参数是否已设：运行SHOW PARAMETER fal，确保fal_server指向备库 TNS 别名（如'dghfdb'），fal_client指向主库自身（如'hfdb'） - 确认备库监听正常且能被主库解析：在主库服务器上
tnsping dghfdb必须成功；同时检查备库listener.ora中是否允许主库 IP 连入 - 触发手动拉取：在备库执行
ALTER SYSTEM ARCHIVE LOG CURRENT;，强制主库切日志并触发 FAL 请求；若仍不生效，可临时ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE;再试
归档真没了？用 RMAN 增量备份修复 Gap
主库归档已删，FAL 失效，这是最常见也最需谨慎操作的场景。核心是：以备库当前 SCN 为起点，在主库做增量备份，再在备库恢复。整个过程不依赖归档，但要求主库保留足够的增量变更块：
- 在备库查当前 SCN：
SELECT CURRENT_SCN FROM V$DATABASE;记下数值（如750923） - 在主库用 RMAN 执行：
BACKUP INCREMENTAL FROM SCN 750923 DATABASE FORMAT '/tmp/incr_%U';—— 注意不要加PLUS ARCHIVELOG，纯数据文件增量即可 - 把备份片拷到备库相同路径（或修改
FORMAT指向本地磁盘），然后在备库 RMAN 中注册：CATALOG START WITH '/tmp/incr_'; - 关键一步：停掉 MRP，否则恢复会冲突：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;，再执行RECOVER DATABASE NOREDO; - 恢复完成后，重启应用：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;
为什么不能直接重建备库或删配置
重建备库耗时长、业务中断久，而单纯删 LOG_ARCHIVE_DEST_n 只是掩盖问题：主库内存中仍残留 DG 状态，下次切日志可能触发 ORA-16038 或归档堆积；更危险的是，如果误删的是 LOG_ARCHIVE_CONFIG，会导致所有 DG 成员失联。真正要清理的，是 Gap 本身，不是配置表象——尤其当备库只是暂时落后，而非彻底不可用时，增量恢复是唯一兼顾效率与安全的选择。
