Redo Routing 是 Data Guard 在级联备库（Cascaded Standby）场景下自动启用的重做转发机制，即备库B将主库A发来的重做日志原样转发给下游备库C；它依赖B处于MANAGED STANDBY RECOVER模式、网络连通、密码文件一致等前提，且仅支持一级级联。
什么是 Redo Routing，它和 Cascaded Standby 什么关系
redo routing 不是独立功能，而是 data guard 在级联备库（cascaded standby）场景下自动启用的重做传输行为：主库 a → 备库 b → 备库 c，当 b 同时作为 c 的上游时，b 会把收到的 a 的归档或实时重做流，原样转发给 c。这个“转发动作”就是 redo routing。
它默认开启，不需要手动配置 LOG_ARCHIVE_DEST_n 中的 REOPEN 或 ALTERNATE 等复杂参数；但必须满足几个硬性前提：
- B 必须处于
MANAGED STANDBY RECOVER模式（即正在应用日志），否则不会转发 - B 的
LOG_ARCHIVE_DEST_STATE_n对 C 的目标必须为ENABLE - B 到 C 的网络连通、密码文件一致、
DB_UNIQUE_NAME在LOG_ARCHIVE_CONFIG中已声明 - C 不能是快照备库（Snapshot Standby），否则 B 拒绝向其发送重做
如何确认 Redo Routing 实际在工作
光看参数不等于生效。最直接的方式是查 B 上的动态视图和归档日志路径：
- 查
V$ARCHIVE_DEST_STATUS：关注DESTINATION是 C 的那行，STATUS应为VALID，TRANSMIT_MODE为ASYNC或SYNC，RECOVERY_MODE为MANAGED REAL TIME APPLY（说明 B 正在接收并可能转发） - 查
V$DATAGUARD_STATS：若NAME = 'transport lag'和'apply lag'都有值，且 C 的 apply lag 明显大于 B 的，说明 B 到 C 的链路存在延迟，Redo Routing 已介入 - 登录 B，执行
ls -lt $ORACLE_HOME/dbs/arch/（或你设的LOG_ARCHIVE_DEST_2路径），看是否有刚生成的、目标为 C 的归档（如1_1234567890_1234567890.arc），再登录 C 查同名文件是否出现
常见中断现象和定位命令
Redo Routing 中断时，C 往往“静默失联”，没有明显报错，只表现为日志不再更新。典型表现和排查顺序如下：
-
ORA-16766: Redo Transport Service is OFF：B 上执行SELECT STATUS FROM V$DATAGUARD_PROCESS WHERE PROCESS = 'RFS'，若返回空或NOT ACTIVE，说明 RFS 进程没起来 —— 很可能是 C 的监听没启，或tnsnames.ora里 C 的别名解析失败 - B 的 alert.log 出现
LGWR: Failed to archive log+ORA-12541: TNS:no listener：说明 B 尝试连 C 失败，优先检查 C 的lsnrctl status和listener.ora是否绑定了正确地址和端口 - C 的
V$ARCHIVED_LOG中APPLIED = 'NO'的记录持续增长，且REGISTRAR = 'RFS'：说明重做已到 C，但 MRP 进程卡住 —— 可能因 C 缺少归档日志间隙（gap）、或控制文件不是最新（比如用旧备份启动过） - B 的
LOG_ARCHIVE_DEST_2设置了VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE)，但 B 当前是主库（switchover 未完成）：此时该 dest 自动失效，Redo Routing 断开
级联深度与性能影响的实际限制
Oracle 官方支持最多一级级联（A→B→C），不推荐 A→B→C→D。这不是语法限制，而是现实瓶颈：
- 每多一级，apply lag 至少叠加 1–3 秒（取决于网络 RTT、磁盘 IO、B 的 CPU 压力），C 的数据新鲜度会显著劣于 B
- B 同时承担：接收 A 的 RFS、本地 MRP 应用、转发日志给 C 的 LNS —— 若 B 的
DB_CACHE_SIZE或LOG_BUFFER不足，可能触发大量 log file sync 等待，拖慢自身恢复速度 - 如果 B 启用了 ADG（Active Data Guard），转发重做时仍走 RFS/LNS，但
STANDBY_FILE_MANAGEMENT=AUTO对 C 无效 —— C 的新增数据文件需手动拷贝或通过CREATE DATAFILE ... AS COPY补齐 - 切换操作复杂度陡增：switchover A→B 后，C 的
LOG_ARCHIVE_DEST_1仍指向旧 A，必须人工修改并 reload，否则 Redo Routing 永久中断
真正麻烦的从来不是配通，而是某天 B 临时宕机重启后，C 没人去 verify gap、没人 check RFS 是否自动拉起、没人确认 LOG_ARCHIVE_DEST_STATE_2 还是不是 ENABLE —— 这些细节松动一次，级联就断一次，而且很难第一时间察觉。
