v$archive_gap有结果即RFS已断，LOW_SEQUENCE#至HIGH_SEQUENCE#为真实缺失归档范围；需主库查文件路径并确认未删除，再手动注册到备库并启MRP；若归档已删则须用增量备份恢复。
直接看 v$archive_gap，有结果就说明RFS确实没收到归档——不是“可能断”，是已经断了。 别信v$archived_log里最大SEQUENCE#，它只反映已入库的归档，不反映缺口；也别等FAL自动拉，11g里FAL静默失效太常见，alert.log没报错≠没失败。
怎么确认GAP范围和位置
在备库执行：SELECT * FROM v$archive_gap;
输出的LOW_SEQUENCE#到HIGH_SEQUENCE#就是RFS缺失的真实归档段。注意：多行代表缺口不连续；RAC环境必须按THREAD#分别查、分别处理。
接着去主库找这些归档文件路径：SELECT NAME FROM v$archived_log WHERE THREAD# = 1 AND SEQUENCE# BETWEEN 95 AND 99 AND DEST_ID = 1;
确保DELETED = 'NO'，否则拷过去也没用——FAL请求返回空，Oracle连错误都不记。
- 如果
v$archive_gap返回空行：问题不在RFS接收层，而在MRP应用层（比如卡在ORA-01111或归档目录I/O慢） - 如果主库
v$archived_log查不到对应序列号：可能是CONTROL_FILE_RECORD_KEEP_TIME设得太小，或归档已被DELETE INPUT清理 - 路径中含ASM？用
ASMCMD的cp命令，别用scp直接传裸设备路径
手动注册归档的实操要点
只要主库归档还在、网络通、TNS能解析，手工注册比等FAL快得多，且可控性强。
步骤顺序不能错：
① scp或ASMCMD cp把归档文件复制到备库本地归档目录（如/u01/arch/），chown oracle:oinstall，chmod 644
② 在备库执行注册：ALTER DATABASE REGISTER PHYSICAL LOGFILE '/u01/arch/1_95_1164727119.dbf';
③ 注册完立刻启动恢复：ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;
- 注册命令必须带
PHYSICAL关键字，否则会报ORA-16014 - 路径名要和
v$archived_log.NAME完全一致（含大小写、扩展名），否则MRP找不到文件 - 一次注册一个文件最稳；批量注册时，
LOW_SEQUENCE#到HIGH_SEQUENCE#之间每个都要单独执行REGISTER
归档已删？只能走增量备份路线
当v$archive_gap有值，但主库v$archived_log查不到对应SEQUENCE#，且确认归档物理删除、无备份时，必须用基于SCN的增量恢复。
关键动作：
① 备库查当前SCN：SELECT current_scn FROM v$database;（记得SET NUMWIDTH 20防科学计数法）
② 主库RMAN做增量备份：BACKUP INCREMENTAL FROM SCN 14968833842954 DATABASE FORMAT '/backup/incr_%U';
③ 同时备份备库控制文件：BACKUP CURRENT CONTROLFILE FOR STANDBY FORMAT '/backup/standby.ctl';
④ 备库startup nomount → RMAN RESTORE STANDBY CONTROLFILE → ALTER DATABASE MOUNT STANDBY DATABASE → RMAN RECOVER DATABASE NOREDO
- 增量备份前，主库最好做过一次全备（非强制，但RMAN推荐）
-
RECOVER DATABASE NOREDO不会去读归档，只应用增量备份块，所以不怕GAP - 11g备库恢复完必须
ALTER DATABASE OPEN READ ONLY再启MRP，否则报ORA-16004
真正容易被忽略的是：FAL_SERVER配置对了，不代表它真在干活——它不检查主库归档是否存在，只管发请求；归档删了、权限不对、TNS指向错的DB_UNIQUE_NAME，它都静默放弃，连alert日志都不写一行。
