RFS（Remote File Server）进程 在 Data Guard 环境中的定位、原理、参数、诊断与最佳实践

系统梳理 **RFS（Remote File Server）进程** 在 Data Guard 环境中的定位、原理、参数、诊断与最佳实践。

---

## 一、RFS 进程的定位

RFS 是**只在物理备库（Physical Standby）或快照备库（Snapshot Standby）上才会出现的后台进程**，负责把主库通过网络传送过来的 Redo 数据接收到本地，并立即写入**Standby Redo Log（SRL）**或归档目录。它是 Data Guard 日志传输链路里“最后一英里”的落地者，与主库的 **LNSn（Log Network Server）** 进程遥相呼应，共同构成“发—收”闭环。

---

## 二、RFS 的工作阶段

### 1. 监听与握手
实例启动后，RFS 进程（可多进程，默认 1–5 个）由 Data Guard Broker 或 `LOG_ARCHIVE_DEST_n` 参数触发，提前在备库监听端口（通常是 1521）上注册服务名；主库 LNSn 通过 Oracle Net 建立长连接，完成双向认证与协商（SYNC/ASYNC、压缩、SSL 等）。

### 2. 接收与写盘
- **SYNC 模式**：LNSn 会等待 RFS 把 redo 块写入 SRL 并返回“落盘 ACK”，才向主库 LGWR 发送“提交完成”。此时 RFS 的 I/O 延迟直接决定主库 commit 延迟。
- **ASYNC 模式**：LNSn 异步发送块，RFS 收到后先放入内存 buffer，再批量写 SRL；主库不等待 ACK，吞吐量更高。

### 3. 归档与切换
当主库发生日志切换，LNSn 会发送“EOF”标记；RFS 收到后立刻触发本地归档（如果 SRL 写满或切换），生成与主库同名同 sequence# 的归档文件，供后续 MRP 进程应用。

---

## 三、RFS 与 Standby Redo Log 的关系
能否实现 **实时应用（Real-Time Apply）** 与 **零数据丢失（Zero Data Loss）**，关键在于备库是否提前配置好**与主库日志成员大小、组数完全一致的 SRL**。RFS 只会把数据写到 SRL；若 SRL 不存在，则退而归档目录，实时性降为“归档应用”。

---

## 四、核心参数与视图

| 参数/视图 | 说明 |
|-----------|------|
| `LOG_ARCHIVE_DEST_n` | 主库端定义 `SERVICE=standby SYNC AFFIRM` 或 `ASYNC NOAFFIRM`，决定 RFS 工作模式。 |
| `STANDBY_FILE_MANAGEMENT=AUTO` | 让备库自动同步新增数据文件，减少 RFS 写归档时的文件空洞。 |
| `DB_CREATE_FILE_DEST` / `DB_CREATE_ONLINE_LOG_DEST_n` | 配合 OMF，自动创建 SRL。 |
| `V$MANAGED_STANDBY` | 查看 RFS 进程状态、序列号、写盘延迟。 |
| `V$DATAGUARD_STATS` | 给出 RFS 造成的“传输延迟（transport lag）”秒数。 |
| `V$STANDBY_LOG` | 显示 SRL 组号、大小、是否被 RFS 占用。 |

---

## 五、常见等待与诊断思路

| 等待事件 | 含义 | 调优要点 |
|----------|------|----------|
| `log file sync (on standby)` | 主库 SYNC 模式下，RFS 写 SRL 慢导致 LNSn 无法及时返回 ACK。 | 把 SRL 放在高速低延迟存储（NVMe、PMem），关闭备库冗余 RAID5/6。 |
| `RFS random i/o` | 11g 及以前若 SRL 与数据文件混放在机械盘，随机 I/O 导致写放大。 | 12c 后 RFS 使用 Sequential I/O 算法；仍建议 SRL 单独组。 |
| `SQL*Net more data to client` | 网络带宽不足或 MTU 不匹配，RFS 接收包分片。 | 开启 SDU=32767 + 9k Jumbo Frame + 网络压缩。 |

---

## 六、RFS 多进程与负载均衡
- 从 11gR2 开始，若定义了多个 `LOG_ARCHIVE_DEST_n` 指向同一备库（不同服务名），或者 Broker 配置 `Preferred/Available`，Oracle 可启动**多个 RFS 进程**（最多 30 个）接收不同线程/实例的redo，提升 RAC→RAC 场景吞吐量。
- 在 multi-standby 拓扑中，每个备库都会有一组 RFS；主库的 LNSn 与它们一对一或一对多，形成星形结构。

---

## 七、Far Sync 场景下的 RFS
当主库与远端备库相隔千里，可把 RFS 部署在**近城 Far Sync 实例**上：
1. 主库 LNSn → Far Sync SRL（SYNC，延迟 < 1 ms）；
2. Far Sync RFS → 远端备库 RFS（ASYNC，带宽友好）。
这样既保证零数据丢失，又避免同步长距离网络抖动对主库性能的冲击。

---

## 八、典型故障与恢复案例

| 现象 | 根因 | 处理 |
|------|------|------|
| 主库 alert 报“LGWR: waiting for FAL” | 备库 RFS 无法打开 SRL，空间满或权限错。 | 备库加组或扩盘，检查 `chmod 640` / `chown oracle:oinstall`。 |
| 备库 alert 报“RFS: Invalid SCN” | 主库 force logging 未开，产生 nologging 块。 | 主库 `ALTER DATABASE FORCE LOGGING;` 并重传增量备份。 |
| `V$MANAGED_STANDBY` 中 RFS 状态 IDLE，sequence# 不前进 | 网络防火墙 30 分钟丢空闲连接。 | 设置 `SQLNET.EXPIRE_TIME=2` 发心跳，或开 keepalive。 |

---

## 九、最佳实践 10 条
1. SRL 组数 = Online Redo 组数 + 1，大小完全一致。
2. SRL 放在独立挂载点，磁盘转速≥ 10 k RPM 或全闪；关闭写缓存保护。
3. 主库 `LOG_ARCHIVE_DEST_n` 务必写 `REOPEN=30 MAX_FAILURE=3 NET_TIMEOUT=30`，防止网络抖动即永久断链。
4. 备库 `DB_BLOCK_CHECKSUM=FULL`，让 RFS 写盘时即校验，提前发现坏块。
5. 定期 `ALTER SYSTEM SWITCH LOGFILE;` 观察 RFS 能否在 5 秒内完成切换写盘。
6. 使用 `V$DATAGUARD_PROCESS` 12c 新视图，可看到 RFS 的 PID、状态、收发字节。
7. 对高并发 OLTP，可设置 `_MAX_RFS_PROCESSES=10`（隐含参数）提升并行接收。
8. 跨云传输，打开 `COMPRESSION=ENABLE` 减少 40–60 % 带宽；CPU 占用 < 5 %。
9. 遇到“台风级”网络断链，优先重启备库监听，再主库 `ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_n=DEFER/ENABLE` 快速重连，比重启实例快。
10. 纳入监控：Prometheus + Oracle Exporter 采集 `transport_lag` > 30 s 即告警，早于用户投诉。

---

## 十、小结
RFS 进程看似只是“写日志”，实则承担了 Data Guard 数据保护策略能否落地的最后一环：
- 在 SYNC 模式下，它决定主库 commit 延迟；
- 在 ASYNC 模式下，它决定备库同步延迟；
- 在实时应用模式下，它决定备库查询一致性。

掌握 RFS 的启动原理、写盘路径、等待事件和调优手段，是运维高可用、零数据丢失架构的基本功。希望本文能成为你现场排障、架构设计时的速查手册。