Oracle Data Guard的RPO由日志传输延迟与MRP应用延迟共同决定，非仅依赖配置模式；实操需监控SCN差值、归档应用状态及时间戳同步性，Failover测试须涵盖应用层验证与DML写入检查。
直接看日志传输延迟和应用延迟
Oracle Data Guard 的 RPO 不是靠“配置模式”直接保证的，而是由 log_archive_dest_2 实际传输延迟 + 备库 MRP 进程应用延迟共同决定。哪怕你配了 SYNC 模式，只要网络抖动或备库 I/O 压力大，MRP 落后几个 SCN，RPO 就大于 0。
实操建议：
- 用
SELECT MAX(SEQUENCE#),APPLIED FROM V$ARCHIVED_LOG WHERE DEST_ID=2 GROUP BY APPLIED;查备库归档接收与应用状态 - 对比主库当前 SCN：
SELECT CURRENT_SCN FROM V$DATABASE;和备库已应用 SCN：SELECT MIN(APPLIED_SCN) FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID=2; - 持续采集差值（单位：秒），用
(CURRENT_SCN - APPLIED_SCN) * (平均事务间隔时间)估算 RPO，比单纯看“是否 SYNC”更真实
Failover 测试必须包含应用层验证
RTO 不只是数据库切主耗时，更是业务恢复时间。很多 DBA 测出 30 秒切换，但应用连不上新主库、连接池没刷新、中间件缓存未失效，实际 RTO 可能翻倍。
关键动作：
- 在测试前，确保应用使用的是服务名（如
ron_app.example.com）而非硬编码 IP 或 SID - Failover 后立即执行带 DML 的验证 SQL：
INSERT INTO test_dr VALUES (SYSDATE); COMMIT;—— 只查SELECT无法暴露 UNDO 或闪回日志缺失问题 - 检查序列跳号：
SELECT last_number FROM dba_sequences WHERE sequence_name = 'SEQ_ORDER_ID';，若业务代码没处理 gap，会直接报错中断
最大保护模式 ≠ 零 RPO 生产可用
MAXIMUM PROTECTION 模式下，主库事务提交前必须等至少一个备库持久化 redo，网络延迟 >10ms 或备库写入慢，主库就会卡住。这不是理论风险，而是银行核心系统上线前压测中高频出现的现象。
踩坑点：
- 跨机房部署时，即使专线 RTT 稳定在 5ms，突发丢包也会触发 LGWR 等待超时，主库挂起
- 备库启用
STANDBY_FILE_MANAGEMENT=AUTO时，新增数据文件操作可能阻塞主库 DDL - 未配置
FAL_SERVER时，归档 GAP 无法自动拉取，MRP 停摆，RPO 持续扩大
SCN skew 是 RPO 隐形杀手
主备时间戳差超过 5 秒，大概率意味着 SCN 已不同步。这会导致后续闪回、补日志失败，甚至误判故障点——比如你以为备库只差 2 秒，实际因 SCN skew 导致逻辑上已不可逆。
必须定期核对：
- 主库执行：
SELECT SYSTIMESTAMP FROM DUAL; - 备库执行同一条语句，对比输出（不是服务器系统时间，是 Oracle 内部时钟）
- 若差值 >5 秒，立刻查
V$DATAGUARD_STATS中apply lag和transport lag，别只盯着STATUS是否为APPLYING_LOG
真正影响 RPO 和 RTO 的，从来不是配置命令写得对不对，而是日志能不能按时发出去、备库能不能按时写进去、应用能不能认出新主库、时间戳有没有悄悄漂移。这些点不逐个压测过，任何 RPO=0 或 RTO<30s 的承诺都只是纸面指标。
