必须人工介入补全日志或跳过断点，先在备库执行select thread#, low_sequence#, high_sequence# from v$archive_gap确认缺口存在，再主库定位路径、备库注册缺失归档并执行recover standby database。
Oracle Data Guard出现GAP，本质是备库缺失一个或多个归档日志文件，导致MRP（Managed Recovery Process）卡住、V$ARCHIVE_GAP有返回结果、applied='NO'的日志堆积——**不能靠等它自动恢复，必须人工介入补全日志或跳过断点**。
怎么确认真有GAP，而不是误报？
别一看到告警就动手。先验证是否真缺日志：
- 在备库执行
SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;—— 有行返回才说明存在gap区间 - 查备库归档接收情况：
SELECT NAME, SEQUENCE#, APPLIED FROM V$ARCHIVED_LOG WHERE SEQUENCE# BETWEEN &low_seq AND &high_seq ORDER BY SEQUENCE#;，确认这些序列号的文件是否真的不存在或APPLIED='NO' - 查主库传输状态：
SELECT STATUS, ERROR FROM V$ARCHIVE_DEST WHERE DEST_ID = 2;，如果STATUS是ERROR且ERROR含ORA-12514，问题出在TNS连接，不是gap本身 - 注意Broker场景：若用DGMGRL管理，
ORA-16724常是Broker配置文件（.dat）和SPFILE中LOG_ARCHIVE_DEST_2不一致导致，不是日志真丢了——先跑SELECT DEST_ID, PROPERTY_VALUE FROM V$DATAGUARD_CONFIG;比对实际生效路径
归档还在主库，只是没传到备库：补日志+注册+recover
这是最轻量的修复方式，适用于网络抖动、临时阻断（如LOG_ARCHIVE_DEST_STATE_2=DEFER）后归档仍完整保留在主库的情况：
- 在备库查gap范围：
SELECT * FROM V$ARCHIVE_GAP;，记下LOW_SEQUENCE#和HIGH_SEQUENCE# - 主库定位对应归档路径：若用ASM，先用RMAN拷出：
COPY ARCHIVELOG '+DG1/.../thread_1_seq_7057.xxx' TO '/tmp/thread_1_seq_7057.xxx'; - 用
scp把缺失的归档文件复制到备库的LOG_ARCHIVE_DEST_1目录（即log_archive_dest_1参数指定的本地归档路径） - 在备库MOUNT状态下执行：
ALTER DATABASE REGISTER PHYSICAL LOGFILE '/path/to/1_7057_XXXX.dbf';（每个缺失文件都要注册） - 再执行：
RECOVER STANDBY DATABASE;—— 它会从第一个gap日志开始连续应用，直到最新
主库归档已被删，但备库SCN还可用：RMAN增量备份修复
当V$ARCHIVE_GAP显示缺日志，而主库ls -l或RMAN LIST ARCHIVELOG ALL已查不到对应文件时，必须用SCN级增量同步：
- 在备库获取当前SCN：
SELECT CURRENT_SCN FROM V$DATABASE; - 主库用该SCN做增量备份：
RMAN TARGET / RUN { BACKUP INCREMENTAL FROM SCN &scn NUMBER DATABASE FORMAT '/backup/incr_%U'; } - 同时备份备用控制文件：
BACKUP CURRENT CONTROLFILE FOR STANDBY FORMAT '/backup/stby_ctl.bkp'; - 把增量备份+控制文件拷到备库，启动到
NOMOUNT，用新控制文件ALTER DATABASE MOUNT STANDBY DATABASE; - 在备库RMAN中注册备份：
RESTORE CONTROLFILE FROM '/backup/stby_ctl.bkp';→STARTUP MOUNT;→CATALOG START WITH '/backup/incr_'; - 取消当前恢复：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;，再执行：RECOVER DATABASE NOREDO; - 最后重启MRP：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
12c+推荐：用RECOVER STANDBY USING SERVICE一步到位
Oracle 12c起支持直接从主库服务拉取增量并恢复，省去手动拷贝备份文件的步骤，但依赖TNS和服务名正确配置：
- 确保备库
TNSNAMES.ORA里已定义主库服务名（如PRIMARY_DB），且能tnsping PRIMARY_DB通 - 备库启动到
NOMOUNT，RMAN连接：RMAN TARGET / - 执行：
RESTORE STANDBY CONTROLFILE FROM SERVICE 'PRIMARY_DB';→ALTER DATABASE MOUNT; - 关键命令：
RECOVER DATABASE FROM SERVICE 'PRIMARY_DB' NOREDO USING COMPRESSED BACKUPSET; - 该命令会自动在主库触发所需增量、传输、解压、应用全过程；失败时错误信息明确指向TNS或权限问题，比手工流程更易排障
真正容易被忽略的是：GAP修复后，必须检查STANDBY_FILE_MANAGEMENT是否为AUTO，以及新增数据文件是否已在备库自动创建——如果主库在gap期间加了表空间，而备库STANDBY_FILE_MANAGEMENT=MANUAL，即使日志补全，MRP也会因找不到数据文件路径而挂起。
