故障转移演练 / 计划内角色切换
一棵决策树：识别角色变更的类型（计划内主备切换、紧急故障转移，或不涉及生产的演练），并为每种场景给出正确的命令顺序和验证步骤。目标：计划内切换零数据丢失，紧急情况下损失最小，演练时完全不停机。
你想做什么？
选择角色变更的场景。是在主库健康时进行计划内切换（维护/迁移），还是主库确实已宕机需要紧急切换，或是在不触及生产的情况下进行演练/就绪验证？
- 计划内主备切换（switchover）（主库健康）
- 紧急故障转移（主库已宕机）
- 演练 / 就绪测试（不触及生产）
计划内切换 — 先确认是否就绪？
计划内主备切换的目标是零数据丢失。为此，切换前必须确认副本已追上主库（延迟 ~0）且状态健康。使用下面的命令检查延迟；如果延迟接近零，继续执行切换步骤。
SELECT thread#, MAX(sequence#) FROM v$archived_log GROUP BY thread#; -- DG: SELECT name, value FROM v$dataguard_stats WHERE name LIKE '%lag%';- 延迟接近零，可以切换
- 延迟较高，先等待同步
计划内主备切换（无数据丢失的受控切换）
在主库和备库健康且同步时，以受控方式互换角色。顺序很重要：停止写入，确认剩余变更已到达备库，然后移交角色，并将应用重定向到新主库。
紧急切换 — 主库真的宕机了吗？
在强制故障转移之前，确认主库确实不可达，并评估脑裂风险。如果主库实际上仍存活（例如短暂的网络中断），强制切换会导致出现两个独立的可写副本（脑裂）。同时比较延迟，选择数据最新的备库。
-- try to reach the primary: tnsping primary_db; and on the standby: SELECT thread#, MAX(sequence#) FROM v$archived_log GROUP BY thread#;- 是的，主库已宕机 — 强制切换
- 不确定 / 主库可能会恢复
紧急故障转移（主库已宕机，切换有数据丢失风险）
主库不可达，且无法等待其恢复。需要强制提升备库；在异步复制下，最后的部分事务可能会丢失。首要任务是恢复服务，然后确定丢失窗口，并安全地恢复旧主库。
演练 / 就绪测试（在不触及生产的情况下验证）
在不进行真实切换的情况下，证明你已为故障转移做好准备。在不影响生产的前提下，验证副本健康状况、延迟是否可接受以及应用能否被重定向。可选：在隔离的副本上演练一次真实的主备切换。