只要主库还存着对应归档文件，就不用重搭备库；应先查v$archive_gap确认缺口范围，再手动拷贝缺失归档至备库log_archive_dest_2路径，执行alter database register physical logfile注册单个文件，最后启动recover automatic standby database。
只要主库还存着对应归档文件，就不用重搭备库——手动拷贝 + 注册是最直接、最可控的修复方式。关键不是“能不能传”，而是“数据库认不认”。
查清缺口范围：别信v$archived_log，只信v$archive_gap
备库上执行SELECT * FROM v$archive_gap;，输出的LOW_SEQUENCE#和HIGH_SEQUENCE#才是RFS进程真正没收到的日志段。常见错误是看v$archived_log里最大SEQUENCE#是100，就以为缺101，结果v$archive_gap显示缺95–99，白忙活。
- 返回空行 → 没有接收缺口，问题在MRP应用层（比如卡在
ORA-01111） - 返回多行 → 缺口不连续，需逐段处理（尤其RAC环境，
THREAD#不同要分开查） - RAC下必须加
WHERE THREAD# = 1等条件过滤，否则会漏掉某线程的缺口
确认主库是否真有这些归档：路径、权限、ASM状态三者缺一不可
别只查v$archived_log有没有记录，直接去主库归档目录找文件：1_<code>LOW_SEQUENCE#_*.dbf到1_<code>HIGH_SEQUENCE#_*.dbf一个都不能少。哪怕只缺一个，FAL机制就彻底失效。
- 查记录：
SELECT NAME, DELETED FROM v$archived_log WHERE SEQUENCE# BETWEEN 1173 AND 1175;，重点看DELETED = 'YES' - 用ASM？进
ASMCMD确认对应diskgroup是MOUNTED状态，DISMOUNTED时归档根本写不进去 - 路径权限不对（如Oracle用户对
/u01/arch/无读权），scp过去也没用，RFS进程直接跳过
手动注册归档：路径必须匹配LOG_ARCHIVE_DEST_2，且一次一个文件
注册不是“放进去就完事”，必须让控制文件明确知道这个归档存在、可用、属于当前线程。绕过RFS校验的唯一方式就是REGISTER PHYSICAL LOGFILE。
- 先拷到备库和
LOG_ARCHIVE_DEST_2完全一致的路径下（比如/u01/arch/），不是DB_RECOVERY_FILE_DEST - 文件权限必须是
chown oracle:oinstall，否则注册报错ORA-19505 - SQL*Plus中执行：
ALTER DATABASE REGISTER PHYSICAL LOGFILE '/u01/arch/1_1173_1164727119.dbf';（注意：一次只能注册一个文件） - 注册完立刻执行：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;，否则MRP不会自动触发应用
注册后MRP仍不启动？检查FAL配置和alert.log静默失败
FAL不是万能开关，它常因参数缺失静默失败——alert.log里没报错≠没尝试，可能是超时后放弃。手动注册后若恢复仍卡住，大概率是FAL干扰了MRP行为。
- 查备库FAL配置：
SHOW PARAMETER fal，若FAL_SERVER为空，先设：ALTER SYSTEM SET FAL_SERVER='primary_db_unique_name' SCOPE=BOTH; - 但更稳的做法是：注册完立即停MRP再重启：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;，再USING CURRENT LOGFILE DISCONNECT; - 如果
v$dataguard_status里持续出现FAL[client]: Error fetching gap sequence, no FAL server specified，说明FAL根本没启用，别浪费时间调它
最容易被忽略的是：注册路径必须和LOG_ARCHIVE_DEST_2的物理路径完全一致，包括末尾斜杠；另外，REGISTER命令不校验归档内容完整性，所以务必先用strings命令确认文件头含ARCHIVELOG标识，否则可能注册了一个损坏文件却毫无感知。
