主库完全不可用时必须执行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 文件中。
执行 FAILOVER 前必须停掉 MRP 并确认无应用冲突
很多人卡在 ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH 报错，根源是 MRP 进程还在后台争抢日志应用控制权。必须先彻底终止它：
- 执行
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL—— 强制中断当前应用 - 查
SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY，确认MRP行状态为NOT APPLYING或已消失 - 再执行
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH；若仍报错ORA-16139: media recovery required，说明还有未应用的归档，此时不能硬切，需回到上一步检查是否真有 GAP 漏掉
特别提醒：FINISH 不是“尽力而为”，它是原子操作：成功则表示所有已接收日志均已应用完毕；失败则意味着日志链不完整，强行 FAILOVER 后数据库可打开，但可能处于不一致状态（如部分表空间 offline、某些索引失效）。
强制升主后，原主库别再启动，否则可能引发脑裂
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY 或 FAILOVER 成功后，新主库会立即更新控制文件中的 database_role 和 activation#。此时如果原主库被误启（哪怕只是 MOUNT），Oracle 会检测到 activation# 冲突，轻则报 ORA-16664: unable to receive the result from a database，重则因控制文件写入冲突导致实例崩溃。
所以实际操作中，建议在原主库主机层面直接关机或拔网线，而不是只关数据库。等业务验证完新主库稳定运行至少 2 小时后，再考虑是否重建该节点为新备库——那已是另一套流程了。
最易被忽略的一点：FAILOVER 后，所有连接字符串、TNS 配置、应用中间件的数据源地址，必须立刻切换指向新主库；任何残留指向旧主库的请求，都会在几秒内失败并可能触发重试风暴。这不是数据库问题，是运维动作的时效性问题。
