如何配置Data Guard的重做路由Redo Routing_级联备库Cascaded Standby架构

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 的目标必须为 ENABLEB 到 C 的网络连通、密码文件一致、DB_UNIQUE_NAME 在 LOG_ARCHIVE_CONFIG 中已声明C 不能是快照备库（Snapshot Standby），否则 B 拒绝向其发送重做如何确认 Redo Routing 实际在工作光看参数不等于生效。最直接的方式是查 B 上的动态视图和归档日志路径：查 VARCHIVE_DEST_STATUS：关注 DESTINATION 是 C 的那行，STATUS 应为 VALID，TRANSMIT_MODE 为 ASYNC 或 SYNC，RECOVERY_MODE 为 MANAGED REAL TIME APPLY（说明 B 正在接收并可能转发）查 VDATAGUARD_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 往往"静默失联"，没有明显报错，只表现为日志不再更新。典型表现和排查顺序如下： MacsMind 电商AI超级智能客服