data guard灾难恢复演习必须验证rto、rpo和应用接管能力，否则无效；演习前须确认archivelog模式、备用库mount状态与恢复模式、tns连通性、还原点创建四项；failover后需严格测dml、序列连续性、时间戳一致性；结果记录须含rto、rpo、应用响应、回退耗时及reinstate验证五项硬指标。
data guard 灾难恢复演习不是“跑通命令就行”，而是必须验证 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中RECOVERY_MODE字段） - 主库和备用库的
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 <standby_db_unique_name>;</standby_db_unique_name>—— 注意：不是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;在新主库和原主库（如还能启）对比，差值超 5 秒需警惕 SCN skew，可能影响后续闪回或补日志
演习结果记录必须包含的 5 项硬指标
监管检查或内部复盘只认这五条，少一条就算记录无效。
- 从发出
FAILOVER命令到V$DATABASE.OPEN_MODE变为READ WRITE的耗时（单位：秒）—— 这是实际 RTO - 最后一条被应用的归档日志序号：
SELECT MAX(SEQUENCE#) FROM V$ARCHIVED_LOG WHERE APPLIED='YES'; - 切换时刻主库最新归档序号：
SELECT MAX(SEQUENCE#) FROM V$ARCHIVED_LOG WHERE DEST_ID=1;，两者差值即 RPO（以归档数计） - 应用端首次成功
INSERT/UPDATE的响应时间（非连接时间） - 还原点回退耗时：
FLASHBACK DATABASE TO RESTORE POINT before_dr_test;+ALTER DATABASE OPEN RESETLOGS;全流程秒数
真实演习中，最常被忽略的是「还原点回退后，主库是否还能自动重新加入 Data Guard 配置」——这需要提前在 broker 或 DGMGRL 中验证 REINSTATE 流程，而不是假设它能自动恢复。
