主库归档被误删导致备库v$archive_gap出现缺口，须先查缺口范围（select thread#, low_sequence#, high_sequence# from v$archive_gap），再人工补归档或用recover database using service（12c+）/增量备份（11g）修复，最后全备保障链路完整。
主库归档日志被误删后，备库必然出现 V$ARCHIVE_GAP 缺口，FAL[client]: Failed to request gap sequence 错误只是表象，真正卡住的是归档传输链——主库已无对应 archivelog 可供发送。不能等自动拉取，必须人工干预补缺或绕过。
查清缺口范围：先在备库跑 V$ARCHIVE_GAP
这是所有操作的起点，不确认缺口就无法选策略。执行：
SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;
注意：LOW_SEQUENCE# 和 HIGH_SEQUENCE# 是闭区间，比如返回 1, 10, 12，表示缺失序列号 10、11、12 三个归档（不是“从10到12之间”）。常见错误是只补了 10，漏掉 11 和 12，导致后续仍报错。
- 若查询结果为空，但备库
APPLIED滞后，说明归档已传但未应用，先检查MRP进程是否运行：SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY WHERE PROCESS = 'MRP0'; - 若
HIGH_SEQUENCE#远高于主库当前最大归档序列（SELECT MAX(SEQUENCE#) FROM V$ARCHIVED_LOG），说明主库已切换多次，缺口扩大，增量恢复更稳妥
优先尝试手工补归档：从备库自身或备份介质还原
别急着做增量备份。如果备库本地还有对应归档（比如 DEST_ID = 1 的本地归档路径未清理），或你有 RMAN 备份集、tar 包、磁带镜像，直接还原比重建同步快得多。
关键动作不是 cp，而是 CATALOG：
- 先在备库查归档物理路径：
SELECT NAME FROM V$ARCHIVED_LOG WHERE SEQUENCE# IN (10,11,12) AND DEST_ID = 1; - 用
scp或rsync拷贝文件到备库一个临时目录（如/tmp/gap_arch/），**不要直传到DB_RECOVERY_FILE_DEST** - 进 RMAN：
RMAN TARGET /，然后执行：CATALOG START WITH '/tmp/gap_arch/'; - 验证是否注册成功：
LIST ARCHIVELOG FROM SEQUENCE 10 UNTIL SEQUENCE 12;，输出中STATUS必须为A（Available）
若 CATALOG 报错说“already cataloged”，说明控制文件里已有同名记录但状态异常，需先 CHANGE ARCHIVELOG ... UNCATALOG; 再重试。
主库归档彻底丢失时：12c+ 推荐用 RECOVER DATABASE USING SERVICE
Oracle 12c 引入该命令，本质是让备库通过网络直连主库，实时拉取所需块变更，绕过归档日志层。它比传统增量备份省去备份传输、控制文件替换、RECOVER NOREDO 等步骤，但要求主库处于 OPEN 状态且监听正常。
- 确认主库
DB_UNIQUE_NAME在备库TNSNAMES.ORA中已定义（如PRIMDB） - 在备库执行：
RECOVER DATABASE FROM SERVICE PRIMDB USING COMPRESSED BACKUPSET;（加COMPRESSED可减少网络压力） - 若报错
ORA-16698: cannot create a log archive destination when the database is using a standby database，说明备库LOG_ARCHIVE_DEST_2配置冲突，临时ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='' SCOPE=BOTH; - 该命令会自动识别备库当前 SCN，并从主库拉取差异数据块，完成后直接
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;
注意：USING SERVICE 不会修复已损坏的数据文件，仅同步逻辑块；若主库在缺口期间执行过 NOLOGGING 操作，这部分变更仍会丢失。
11g 或必须用增量备份时：SCN 对齐比序列号更可靠
当主库版本低于 12c，或网络不可达、主库负载过高禁用 service 恢复时，回到经典增量流。但别按网上教程盲目用 FROM SCN —— 若主库刚执行过 RESETLOGS，V$DATABASE.CURRENT_SCN 可能跨 resetlogs 边界，导致增量备份包含无效块。
- 在备库查最老数据文件头 SCN：
SELECT MIN(CHECKPOINT_CHANGE#) FROM V$DATAFILE_HEADER WHERE FILE# NOT IN (SELECT FILE# FROM V$DATAFILE WHERE ENABLED = 'READ ONLY'); - 主库 RMAN 执行：
BACKUP INCREMENTAL FROM SCN <scn_from_standby> DATABASE FORMAT '/bak/incr_%U' TAG 'DG_RECOVER';</scn_from_standby> - 备库恢复前，必须用
RESTORE STANDBY CONTROLFILE FROM ...替换控制文件，否则RECOVER DATABASE NOREDO会因控制文件中归档序列断档而失败 - 恢复后启动 MRP 前，务必检查
V$MANAGED_STANDBY中CLIENT_PROCESS是否为LGWR（非ARCH），否则仍走归档路径，再次卡在缺口
最后提醒：所有恢复操作后，立即在主库执行一次全备（BACKUP DATABASE PLUS ARCHIVELOG），因为 CLEAR UNARCHIVED LOGFILE 或 USING SERVICE 都可能造成归档链不可逆断裂，下次再丢日志就真没退路了。
