failover是主库彻底不可用时的强制接管而非切换，执行后原主库角色丢失、dg配置断裂，须人工重建；主库可mount时优先flush redo保数据，完全宕机时依赖v$archive_gap填补日志缺口，最终通过cancel、finish、open完成接管，并立即修正归档参数、应用连接及原主库恢复流程。
Failover 是主库彻底不可用时的强制接管，不是“切换”，而是重建主库的起点；执行后原主库角色丢失、DG 配置断裂，必须人工重建。
主库还能 MOUNT 时：优先 FLUSH REDO 保数据
只要主库实例能启动到 MOUNT 状态（哪怕 OPEN 报错），就还有机会把最后一批未传输的 redo 推过去，争取零丢失。
- 在主库执行：
ALTER SYSTEM FLUSH REDO TO 'stdb_unique_name';—— 注意参数必须是备库的db_unique_name，不是服务名、TNS别名或实例名 - 确认备库已启用日志应用：
SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY WHERE PROCESS = 'MRP0';返回APPLYING_LOG才算有效 - 若
FLUSH REDO成功，直接跳到RECOVER 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 → 补日志 →
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;→ 再查 gap，直到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;（11g 必须先FINISH再OPEN；12c 及以后可直接用ALTER DATABASE OPEN RESETLOGS;） - 验证：
SELECT DATABASE_ROLE, OPEN_MODE FROM V$DATABASE;应为PRIMARY和READ WRITE
最易被忽略的是：Failover 后原主库已脱离 DG 架构，即使它后来恢复，也不能直接加回；必须按新主库备份 + 恢复 + 重建 Standby 流程重新搭建，否则会引发角色冲突或归档覆盖。另外，所有应用连接字符串、TNS 配置、监听器服务名都需同步更新，否则流量仍会打向已失效的旧主库地址。
