必须走RMAN增量备份修复：当V$ARCHIVE_GAP查出缺口，且主库V$ARCHIVED_LOG中对应序列DELETED='YES'或无记录，同时V$ARCHIVE_DEST_STATUS无传输错误，表明归档已被删除，无法通过拷贝注册恢复。
v$archive_gap 查出来有 gap，但 mrp0 进程卡在 wait_for_gap 不动，说明备库明确缺日志，而 fal 机制没拉到——最常见原因就是主库上对应归档已被删除，自动修复彻底失效。这时候必须用 rman 增量备份+新控制文件的方式“滚前”备库。
怎么判断必须走增量备份而不是拷归档？
先确认两点：
- 在备库执行
SELECT * FROM V$ARCHIVE_GAP;，拿到LOW_SEQUENCE#和HIGH_SEQUENCE# - 立刻去主库查：
SELECT NAME, SEQUENCE#, DELETED FROM V$ARCHIVED_LOG WHERE SEQUENCE# BETWEEN &low_seq AND &high_seq;—— 如果DELETED = 'YES'或无返回，归档已丢，拷文件这条路走不通 - 再看主库
V$ARCHIVE_DEST_STATUS的ERROR字段，如果出现ORA-16055或传输路径不可写，gap 可能是传输中断导致，但归档还在；若无错误却查不到日志，基本可断定被 RMANDELETE ARCHIVELOG清掉了
RMAN 增量备份修复的关键步骤顺序不能错
顺序错一步，备库可能无法 mount 或恢复失败：
- 在备库停掉应用：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; - 查备库当前 SCN：
SELECT CURRENT_SCN FROM V$DATABASE;（别用MIN(FHSCN)，11g 下它可能滞后） - 主库执行增量备份：
BACKUP INCREMENTAL FROM SCN &scn DATABASE FORMAT '/tmp/incr_%U' TAG 'FORSTANDBY';—— 注意必须带FROM SCN，不能用LEVEL=1 - 主库生成 standby 控制文件：
ALTER DATABASE CREATE STANDBY CONTROLFILE AS '/tmp/standby.ctl';（不是 backup controlfile） - 把备份片 + 控制文件一起 scp 到备库相同路径，权限保持为 oracle:oinstall
备库恢复时最容易踩的三个坑
实操中近七成失败源于以下细节：
- 没关掉备库的
REDO APPLY就直接启动到MOUNT：必须先SHUTDOWN IMMEDIATE，再用新控制文件STARTUP MOUNT - RMAN 恢复前没
CATALOG START WITH：备份片不在 FRA 或 catalog 中，RMAN 找不到，得手动CATALOG BACKUPPIECE '/tmp/incr_*.bkp'; - 主库在 gap 期间新增过数据文件，但没同步到备库：恢复前必须先在备库
RESTORE DATAFILE &new_file_id;，否则RECOVER DATABASE报ORA-01152
验证是否真正追平，别只信 V$ARCHIVED_LOG
恢复完启动 MRP 后，光看 APPLIED='YES' 不可靠。要交叉验证：
- 查
V$MANAGED_STANDBY：确保MRP0状态是APPLYING_LOG，且SEQUENCE#持续递增 - 比对主备 SCN：
SELECT CURRENT_SCN FROM V$DATABASE;在两边同时执行，差值应 ≤ 10000（取决于日志生成速率） - 查
V$DATAGUARD_STATS的VALUE字段，apply lag和transport lag都应稳定在秒级，不再增长
增量备份修 gap 是兜底手段，过程不可逆。一旦开始，就意味你放弃了从归档日志逐条追平的路径——所以动手前务必确认主库归档真没了，而不是 FAL 配置漏了 FAL_SERVER 或归档目录权限不对。
