rfs进程仅被动接收主库推送的日志，不主动发现或拉取缺失归档；缺口检测与fal补传由mrp触发，依赖其读取时发现归档缺失并报ora-00308后发起请求。
备库RFS进程不主动拉取缺失归档，只被动接收主库推送
RFS（Remote File Server）进程本身不负责“发现缺口并反向请求”，它只做一件事：把主库ARC或LGWR进程发来的归档日志写入本地磁盘。所谓“缺失归档”，是备库MRP（Media Recovery Process）在应用时发现v$archived_log里有SEQUENCE#断层，但RFS对此无感知——它不会查v$archive_gap，也不会发起FAL（Fetch Archive Log）请求。
真正触发补传的是MRP：当它读到一个不存在的归档（比如thread_1_seq_1002），会报ORA-00308，然后内部触发FAL_SERVER机制，向主库FAL_CLIENT发送补传请求。但这个流程能否走通，取决于主库是否还保留该归档。
- 主库归档已被
DELETE ARCHIVELOG或FRA自动清理，FAL_CLIENT就找不到文件，返回ORA-16055或静默失败 - 主库
log_archive_dest_2配置了SYNC但网络超时，FAL重试几次后放弃，不再尝试 - 主库
log_archive_config中未包含备库的db_unique_name，FAL请求被拒绝，alert.log里只有ORA-16057
主库FAL_CLIENT未启用或配置错误
FAL_CLIENT是主库上响应备库补传请求的关键组件。19c默认开启，但容易被显式关闭或参数干扰。如果fal_client为空或指向错误实例，备库发来的FAL请求会被忽略。
检查命令：SHOW PARAMETER fal_client、SHOW PARAMETER fal_server。常见问题包括：
-
fal_client设成了主库自己的db_unique_name，而非备库的——应设为备库的db_unique_name -
fal_server没配，或配了但TNS别名无法解析（tnsping不通） - 主库监听器未启动，或
local_listener指向错误地址，导致FAL连接被拒
归档传输路径配置冗余或冲突
当主库log_archive_dest_2和log_archive_dest_3都指向同一备库，或standby_archive_dest与log_archive_dest_1路径相同，RFS可能因文件已存在而拒绝写入，产生ORA-16401提示，但FAL补传逻辑会被干扰甚至跳过。
19c对路径校验更严格，冗余配置会导致FAL请求被路由到错误DEST_ID，或被RFS静默丢弃。关键动作是清理无效路径：
- 查冗余项：
SELECT DEST_NAME, STATUS, TARGET FROM V$ARCHIVE_DEST WHERE TARGET = 'STANDBY' - 禁用误配项：
ALTER SYSTEM SET log_archive_dest_3='' SCOPE=BOTH - 清除废弃参数：
ALTER SYSTEM RESET standby_archive_dest SCOPE=SPFILE（需重启）
备库控制文件未记录归档缺失，MRP根本不触发FAL
这是最隐蔽的坑：v$archive_gap为空，但实际归档已断。原因通常是备库控制文件太旧——比如用冷备份创建后没做完整recover，或上次RECOVER MANAGED STANDBY DATABASE中断，导致控制文件里的next_scn没更新。
此时MRP认为“当前已应用到最新”，不会去读后续归档，自然不报错也不触发FAL。验证方式：
- 查
v$managed_standby中MRP0的SEQUENCE#是否停滞不前 - 对比主库
max(sequence#)和备库v$archived_log里最大的SEQUENCE#，差值>1即说明有隐藏gap - 手动触发一次
RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT，看是否立刻报ORA-00308
真遇到这种情况，别等自动拉取——直接从主库拷thread_X_seq_Y归档到备库log_archive_dest_1目录，再执行ALTER DATABASE REGISTER PHYSICAL LOGFILE 'xxx'注册，才能让MRP继续跑下去。
