容灾演练前必须确认主库switchover_status为to standby、备库open_mode为mounted且mrp0状态为applying_log，否则90%的演练会在sessions active或not allowed状态卡住。
容灾演练前必须确认的三个状态
不验证就切，90%的演练会卡在 switchover_status 为 SESSIONS ACTIVE 或 NOT ALLOWED。必须逐项检查主库和备库的实时状态：
-
SELECT database_role, open_mode, protection_mode, switchover_status FROM v$database;—— 主库需为PRIMARY且switchover_status是TO STANDBY；备库需为PHYSICAL STANDBY且open_mode是MOUNTED - 确认
ARCHIVE_LAG_TARGET已设（建议 60～180 秒），避免因归档延迟导致日志堆积、MRP进程卡住 - 检查
v$managed_standby中PROCESS列：确保MRP0状态为APPLYING_LOG，而非WAIT_FOR_LOG或CONNECTED
手动switchover 的标准操作链
不是执行一条 ALTER DATABASE COMMIT TO SWITCHOVER 就完事。真实环境里，漏掉任意一步都可能触发回滚失败或角色混乱：
- 主库先执行：
ALTER DATABASE COMMIT TO SWITCHOVER TO STANDBY WITH SESSION SHUTDOWN;—— 注意必须加WITH SESSION SHUTDOWN，否则残留连接会阻塞切换 - 备库立刻执行：
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;—— 必须在主库完成后的 5 分钟内执行，超时将进入不可逆的FAILED状态 - 原主库启动后，必须用
STARTUP MOUNT，再执行ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;—— 不是OPEN，否则会报错ORA-16139: media recovery required
应用层无感切换的关键配置点
数据库切过去了，但应用连不上，问题大概率出在连接层。Data Guard 本身不解决 DNS 或连接池重连，必须提前对齐：
- TNS alias 中的
(FAILOVER=ON)和(FAILOVER_MODE=(TYPE=SESSION)(METHOD=BASIC))是基础，但不够——Java 应用还需在 JDBC URL 加&failover=true参数，否则Connection对象不会自动重试 - Oracle Wallet 中的证书若绑定主机名，切换后新主库 IP/主机名不匹配，会导致 SSL 握手失败；建议用通配符证书或切换前更新 Wallet
- 应用连接池（如 HikariCP）的
connection-test-query必须设为轻量级语句（如SELECT 1 FROM DUAL），避免在切换瞬间因长查询阻塞检测线程
演练后必须立即验证的两个一致性断点
很多人只看 SELECT MAX(SEQUENCE#) FROM V$LOG_HISTORY，这只能说明日志传过来了，不代表数据已应用。真正要盯的是：
- 主库当前 SCN：
SELECT CURRENT_SCN FROM V$DATABASE; - 备库已应用 SCN：
SELECT APPLIED_SCN FROM V$DATAGUARD_STATS WHERE NAME = 'applied scn'; - 两者差值超过 10000，说明存在滞后；若差值为 0 但应用仍报错，极可能是
STANDBY_FILE_MANAGEMENT=AUTO未启用，导致新增表空间文件未同步
演练结束后的还原动作容易被跳过：原主库恢复为 standby 后，必须手动执行 ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE;，否则下次演练前日志传输会静默中断。
