failover是主库彻底不可用时的强制接管而非切换，执行后dg配置断裂、原主库角色丢失，必须人工重建；主库可mount时优先flush redo保数据，完全宕机时依赖v$archive_gap填补日志缺口，最终通过cancel、finish、open完成接管，并须立即修正归档参数、应用连接及原主库恢复流程。
Failover 是主库彻底不可用时的强制接管，不是“切换”，而是“重建主库”的起点；执行后原主库角色丢失，DG 配置断裂，必须人工重建。
主库还能 mount 时：用 FLUSH REDO 尽量保数据
如果主库实例能启动到 MOUNT 状态（哪怕无法 OPEN），优先走这条路径，目标是把最后一批未传输的 redo 推过去，争取零丢失。
- 在主库执行：
ALTER SYSTEM FLUSH REDO TO 'target_db_unique_name';—— 注意参数必须是备库的db_unique_name，不是服务名或实例名 - 确认备库已启用 redo 应用：
SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY WHERE PROCESS = 'MRP0';返回APPLYING_LOG才算有效 - 执行成功后，跳过 gap 检查直接进
FINISH步骤；失败则退回手动补日志流程
主库完全宕机：靠 V$ARCHIVE_GAP 定位并填补日志缺口
主库服务器离线、磁盘损坏、或连 sqlplus / as sysdba 都进不去时，只能依赖备库自身状态判断缺哪些归档。
- 查 gap：
SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;—— 这个视图只反映“已知缺失”，不包含尚未生成的序列号 - 补日志：从主库残存归档目录（如
+FRA/dbname/archivelog/或文件系统路径）拷贝对应sequence#的归档文件到备库，再注册：ALTER DATABASE REGISTER PHYSICAL LOGFILE '/path/to/arch_1_90_12345.arc'; - 反复查 gap、补日志、重启 MRP 直到
V$ARCHIVE_GAP返回空结果；若某段 gap 对应的归档物理不存在（比如主库归档被自动清理），那这部分数据注定丢失
执行最终接管：RECOVER FINISH 和 ALTER DATABASE OPEN
这一步看似简单，但顺序和状态判断极关键。错一步就会卡在 MOUNTED 或报 ORA-16139: media recovery required。
- 先停应用：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; - 再收尾日志：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;—— 必须成功返回，否则说明还有未应用日志，不能硬开 - 最后打开：
ALTER DATABASE OPEN;（12c 及以后可直接用ALTER DATABASE OPEN RESETLOGS;，但 11g 必须先FINISH再OPEN） - 验证：
SELECT DATABASE_ROLE, OPEN_MODE FROM V$DATABASE;应为PRIMARY和READ WRITE
Failover 后最易被忽略的三件事
很多人以为 OPEN 成功就结束了，其实真正的麻烦才刚开始。
-
LOG_ARCHIVE_DEST_n参数仍指向旧主库地址，新主库会持续报ORA-16057: DGID not in data dictionary，必须立刻修改或禁用 - 原主库恢复后不能直接加回 DG —— 它的控制文件里还记着自己是
PRIMARY，需用FLASHBACK DATABASE回退到 failover 前 SCN，或重建控制文件，否则无法注册为 standby - 所有应用连接字符串、TNS alias、监听器配置里的
service_name都要同步更新，否则业务连的是“幽灵主库”
