failover是主库彻底宕机时唯一可行路径：需先停mrp，查v$archive_gap和v$archived_log评估丢失量，确认无日志缺口后强制升主；原主库须物理隔离，应用连接立即切至新主库。
主库彻底宕机时，Failover是唯一可行路径
当主库服务器断电、存储损坏或数据库连 mount 都失败时，同步补日志已无可能。此时不能等、不能拖，必须执行 FAILOVER——这不是“切换”，而是备库强制升主，且必然伴随数据丢失。
关键判断依据只有一条：SELECT STATUS, GAP_STATUS FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID = 2 在主库上已无法执行，且你确认短期内无法恢复主库访问权限。只要满足这个条件，所有“传归档”“刷日志”的预案都应立即中止，转向损失评估与强制接管流程。
先查缺口：用 V$ARCHIVE_GAP 和 V$ARCHIVED_LOG 估算丢失量
在备库上运行这两个查询，是评估数据丢失范围的唯一直观手段：
-
SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP—— 返回空行？说明没有明显断档；有记录（如THREAD# = 1, LOW_SEQUENCE# = 90, HIGH_SEQUENCE# = 92）？那序列号 90–92 的归档日志根本没到备库，这部分事务必然丢失 -
SELECT THREAD#, MAX(SEQUENCE#) FROM V$ARCHIVED_LOG GROUP BY THREAD#—— 拿这个最大值，和你手头掌握的主库最后归档文件名（如1_89_1234567890.arc）比对；若备库最大是 89，而主库最后生成的是 95，则至少缺失 90–95 共 6 个归档
注意：V$ARCHIVE_GAP 只能发现“已知缺口”。如果主库崩溃前还没来得及归档（即在线日志未触发归档），这部分 redo 只存在于内存或未刷盘的 online redo log 文件中，完全不可见、不可恢复。
执行前必须停掉 MRP，否则 FINISH 必报错
很多人卡在 ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH 报 ORA-16139: media recovery required，根源是 MRP 进程还在后台争抢日志应用控制权。
- 先执行
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL—— 强制中断当前应用 - 再查
SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY，确认MRP行状态为NOT APPLYING或已消失 - 此时再执行
FINISH；若仍报错，说明还有未应用的归档，需回头检查是否漏掉GAP
FINISH 不是“尽力而为”，它是原子操作：成功表示所有已接收日志均已应用完毕；失败则意味着日志链不完整，强行 FAILOVER 后数据库虽可打开，但可能处于不一致状态（如部分表空间 OFFLINE）。
原主库必须物理隔离，应用连接必须立刻切走
Failover 完成后，DG 主从关系即被彻底破坏，两个库变成互不相关的独立实例。
- 原主库服务器必须断网、关机或拔硬盘——任何尝试重启或挂载的行为都可能导致脑裂或数据覆盖
- 所有应用连接必须立即指向新主库的
tnsnames.ora条目或服务名，不能依赖旧连接串或负载均衡器缓存 - Broker 配置已失效，
dgmgrl中的配置需重建，不能复用
最容易被忽略的一点：备库升主后，LOG_ARCHIVE_DEST_n 参数不会自动重写，仍指向原主库地址。若未手动清理或重配，新主库会持续报错 ORA-16057: DGID not set 或归档失败，影响后续备份与日志归档完整性。
