灾难恢复演练必须验证RTO达标、RPO可控、应用真实接管，否则无效；演习前须确认ARCHIVELOG模式、备用库MOUNT状态与RECOVERY_MODE、tnsnames.ora配置及还原点创建四项状态，缺一即大概率卡在第三步或误删归档。
灾难恢复演练不是“跑通 ALTER DATABASE FAILOVER TO 就算成功”，而是必须验证 RTO 是否达标、RPO 是否可控、应用能否真实接管——否则演习等于没做。
演习前必须确认的 4 个状态
没确认就开练，90% 的演习会在第 3 步卡住，甚至误删主库归档。
-
ARCHIVELOG模式已启用，且主库LOG_ARCHIVE_DEST_2指向备用库的路径可写：用ARCHIVE LOG LIST和SELECT DEST_NAME, STATUS, ERROR FROM V$ARCHIVE_DEST;双查 - 备用库处于
MOUNT状态，且RECOVERY_MODE是MANAGED STANDBY RECOVERY（查V$ARCHIVE_DEST_STATUS中该字段） - 主库和备用库的
DB_UNIQUE_NAME在tnsnames.ora中配置正确，客户端能tnsping通两个实例 - 备用库上已创建还原点：
CREATE RESTORE POINT before_dr_test GUARANTEE FLASHBACK DATABASE;——这是回退唯一可靠锚点，别依赖FLASHBACK DATABASE TO TIMESTAMP
执行 failover 的关键命令与风险点
真正故障转移只用一条命令，但前置检查和后续清理决定演习是否可信。
- 停掉主库 Redo 传输：
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=DEFER;（避免切换后日志还在发，导致冲突） - 在备用库执行：
ALTER DATABASE FAILOVER TO——注意：不是; SWITCHOVER，FAILOVER不可逆，必须确保主库已不可用或已关机 - 成功后立即查：
SELECT DATABASE_ROLE, OPEN_MODE FROM V$DATABASE;应返回PRIMARY+READ WRITE - 切完立刻停应用连接主库的连接池，否则旧连接会持续报
ORA-01033: ORACLE initialization or shutdown in progress并拖慢验证
验证应用可用性时最容易漏掉的三件事
连得上不等于能用；能查不等于能改；能改不等于事务一致。
- 测试 SQL 必须含 DML：
INSERT INTO test_dr VALUES (SYSDATE); COMMIT;——只查SELECT无法验证 UNDO、SCN 同步、闪回日志是否完整 - 检查序列和自增列是否跳号：
SELECT last_number FROM dba_sequences WHERE sequence_name = 'XXX';，FAILOVER后序列缓存丢失是常态，业务代码若没处理 gap 会报错 - 确认时间戳一致性：
SELECT SYSTIMESTAMP FROM DUAL;在新主库和原主库（如还能启）上比对，偏差超秒级需排查 SRL 或应用延迟
演习结果必须记录的五项硬指标
没有这五项数据，报告不具备复盘价值，也过不了合规审计。
- RTO：从主库确认宕机到新主库
OPEN_MODE变为READ WRITE的耗时（单位：秒） - RPO：切换时刻，新主库相比原主库丢失的 SCN 数量，通过
SELECT MAX(SEQUENCE#) FROM V$ARCHIVED_LOG对比推算 - 应用响应：首笔业务交易（非健康检查）返回成功的时间点
- 回退耗时：从新主库执行
FLASHBACK DATABASE TO RESTORE POINT before_dr_test到原主库重新MOUNT并启动恢复的总时长 -
reinstate验证：回退后，能否用REINSTATE DATABASE把原备用库重新拉回同步链路，且无 GAP 报错
最常被忽略的是还原点的 GUARANTEE 属性和回退后的 REINSTATE 验证——前者缺失会导致闪回失败，后者跳过则意味着下一次演习前整个 Data Guard 链路实际已失效。
