最准的rto测量需用dgmgrl轮询状态变化并记录时间戳，等database status为success、role变primary后，立即连新主库执行select sysdate from dual验证可用性才算结束。
怎么用 dgmgrl 测主备切换真实耗时
直接在生产环境跑 switchover 是最准的，但不能靠“看表”或“手动掐秒”，得让 dgmgrl 自带计时逻辑介入。关键不是命令本身，而是它执行过程中的状态卡点——比如从发出命令到备库真正变成 primary 并完成实例启动、日志应用、监听就绪，这整段才叫 rto。
实操建议：
- 提前在主库和备库都开启 SQL*Plus 连接，确保
SELECT STATUS FROM V$INSTANCE;可查，避免切换后连不上 - 用
time dgmgrl / @switchover_script.dg包裹（Linux），但注意：这个时间包含网络延迟和本地 shell 启动开销，偏高；更准的是在dgmgrl里用show configuration verbose轮询状态变化，自己记录时间戳 - 必须等
Database Status显示SUCCESS且Role确认为PRIMARY，再立刻连上新主库执行SELECT SYSDATE FROM DUAL;验证可用性——这才是 RTO 的终点
switchover 命令卡住不动？先看这三处日志
常见错误现象是 dgmgrl 执行 switchover to 'xxx'; 后长时间无响应，光标停在那儿。这不是命令没发出去，而是 Data Guard 内部校验失败，卡在前置检查环节。
实操建议：
- 立刻查主库告警日志：
tail -f $ORACLE_BASE/diag/rdbms/xxx/xxx/trace/alert_xxx.log，重点搜ORA-16766（standby not ready）、ORA-16664（无法联系备库） - 查备库
MRP进程状态：SELECT PROCESS, STATUS, THREAD#, SEQUENCE# FROM V$MANAGED_STANDBY;，如果MRP是APPLYING_LOG但SEQUENCE#滞后太多，说明日志堆积，switchover会等应用完才继续 - 检查
LOG_ARCHIVE_DEST_STATE_2是否为ENABLE，以及DB_UNIQUE_NAME在tnsnames.ora中是否拼错——这类配置错误不会报错，但会让dgmgrl无限等待连接
为什么 switchover 成功了但应用连不上
RTO 不只算数据库角色切换时间，还得算客户端重连和服务恢复。很多测试只盯着 dgmgrl 输出 SUCCESS 就停表，结果发现应用报 ORA-01033 或连接超时，实际 RTO 多出几十秒。
实操建议：
- 确认监听器已随实例启动：
lsnrctl status在新主库上必须返回READY状态，否则应用发来的连接请求会被拒绝 - 检查
local_listener和remote_listener参数是否指向新地址，尤其用了 SCAN 或 VIP 的环境，旧 listener 地址可能还在缓存里 - 如果用了连接池（如 Tomcat JDBC Pool），要设
testOnBorrow=true和validationQuery=SELECT 1 FROM DUAL，否则连接池会把失效连接一直留着
测试时要不要关掉 Fast-Start Failover
要关。FSFO 是自动故障转移机制，和人工 switchover 共享同一套心跳与状态判断逻辑。测试中如果 FSFO 意外触发，会导致主备角色混乱、dgmgrl 报 ORA-16666，甚至引发脑裂。
实操建议：
- 测前执行：
DISABLE FAST_START FAILOVER;（在dgmgrl中） - 别只依赖
SHOW CONFIGURATION看输出，一定要补查：SELECT FS_FAILOVER_STATUS FROM V$DATABASE;，值必须是DISABLED - 测试完记得开回去，但注意：FSFO 重启需要重新同步 observer，不是简单
ENABLE就行，容易漏掉这步
RTO 测试最难控的其实是外部依赖——监听器启没启、VIP 漂没漂、DNS 刷新没刷新、连接池清没清。这些不写进脚本，光靠人盯，十次测九次不准。
