RTO不能只看切换命令执行时间，真实RTO包含主库确认不可用、决策干预、应用重连、健康检查及流量切换等环节，常比命令耗时长3–10倍；RPO在跨地域场景下受网络抖动和SYNC降级影响而波动，需监控归档状态与SCN对齐。
rto 不能只看切换命令执行时间
很多人测 ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY 或 FAILOVER 命令耗时，就当 RTO。这是错的。真实 RTO 包含：主库确认不可用的时间（可能要等心跳超时）、切换决策与人工干预耗时、切换后应用重连与连接池重建、服务健康检查通过、业务流量切回——这些加起来往往比命令本身长 3–10 倍。
- Oracle 默认
NetTimeout是 30 秒，主库网络假死时，备库需等满这个周期才触发自动故障转移；若设为 10 秒，可能误切（尤其在高延迟跨域链路） - 应用层 DNS 切换或 VIP 漂移通常有缓存（
TTL），若未设为 30 秒以内，RTO 实际受 DNS 生效时间主导 - 切换后必须验证
SELECT COUNT(*) FROM v$session WHERE status='ACTIVE'和关键业务表可读写，否则应用可能静默失败
RPO 在跨地域场景下会突然变差
同城 Data Guard 的 RPO 通常能压到秒级，但一旦拉远距离（比如上海↔新加坡），ARCHIVE_LAG_TARGET 和网络抖动会让 RPO 不稳定。更关键的是：Oracle 不保证异地备库的 SCN 严格对齐，尤其在突发大事务写入时。
- 启用
SYNC模式无法真正实现零 RPO：只要网络丢包或备库 I/O 延迟 >100ms，Oracle 就自动降级为ASYNC，且不告警 - 跨地域部署必须监控
v$archive_dest_status中的RECOVERY_MODE和STANDBY_LOGFILE_COUNT，后者为 0 表示归档日志传输已中断，RPO 开始线性增长 - 灾难发生前最后一分钟的 DML 若未刷盘到备库的 standby redo log，就会丢失——这和主库是否 commit 无关，只取决于
LGWR SYNC是否实际完成
演习必须模拟“部分失效”，而非全宕机
真实极端灾难极少是主库彻底消失。更常见的是：主库仍能响应简单查询（SELECT 1 FROM DUAL），但事务 hang 住、归档卡死、监听器拒绝新连接。这种“半死”状态最考验 RTO/RPO 评估的真实性。
- 演习时不要直接
kill -9主库进程，而是模拟：停掉ARCn进程 + 手动阻塞归档目标目录写入 + 用iptables限速主备间 9001 端口至 100Kbps - 验证点必须包含：
SELECT MAX(SEQUENCE#) FROM v$archived_log WHERE DEST_ID=2（备库已接收最大日志序号）与主库当前SELECT CURRENT_SCN FROM v$database对应的时间戳偏差 - FAILOVER 后立即查
SELECT SYSTIMESTAMP FROM DUAL，若与原主库（如还能 ping 通）相差 >5 秒，说明存在 SCN skew，后续闪回或补日志可能失败
跨地域 Data Guard 的 RPO 波动本质是网络与存储延迟的函数，不是配置开关能完全控制的；RTO 的瓶颈也早已不在数据库层，而在应用重发现与中间件重路由。漏掉任何一环，测出来的数字都是虚的。
