主库归档丢失后，备库可通过RMAN增量备份+新控制文件恢复，增量起点SCN应取CURRENT_SCN、数据文件头FHSCN、排除只读表空间的FHSCN及缺失归档FIRST_CHANGE#四者最小值；备份须含FOR STANDBY控制文件并建议压缩；恢复需严格按停MRP→启nomount→还原standby控制文件→mount→catalog→检查新增数据文件→recover noredo顺序执行；OPEN READ ONLY后须验证MRP运行状态、主备日志序列差≤1、apply/transport lag非空且正常传输归档。
主库归档日志丢失后，备库出现 V$ARCHIVE_GAP，只要备库没宕机、没重建，就不用重搭 DataGuard——用 RMAN 增量备份 + 新控制文件，能抢救回来。
怎么确定增量起点 SCN？别只看 CURRENT_SCN
备库上查到的 CURRENT_SCN 是一个参考值，但真正安全的起点得取多个来源里的最小值，否则增量备份可能漏掉部分块变更：
SELECT TO_CHAR(CURRENT_SCN) FROM V$DATABASE-
SELECT MIN(FHSCN) FROM X$KCVFH（数据文件头里记录的最低检查点 SCN） -
SELECT MIN(F.FHSCN) FROM X$KCVFH F, V$DATAFILE D WHERE F.HXFIL = D.FILE# AND D.ENABLED != 'READ ONLY'（排除只读表空间影响） - 如果备库有
V$ARCHIVE_GAP输出，也可在主库查对应缺失归档的FIRST_CHANGE#：SELECT FIRST_CHANGE# FROM V$ARCHIVED_LOG WHERE SEQUENCE# = <LOW_SEQUENCE#>
四个结果中取最小值，才是保险的 FROM SCN。实操中常见 CURRENT_SCN 比 FHSCN 大 1～2，用大值会导致恢复后报 ORA-01152: file 1 was not restored from a sufficiently old backup。
RMAN 增量备份必须带 controlfile for standby 和压缩
主库执行增量备份时，BACKUP INCREMENTAL FROM SCN ... DATABASE 只是基础；漏掉以下两项，备库后续无法 mount 或恢复失败：
- 必须显式备份 standby 控制文件：
BACKUP CURRENT CONTROLFILE FOR STANDBY FORMAT '/path/standby_ctrl.bak'。普通BACKUP CURRENT CONTROLFILE不适用，它不含 standby 所需的 resetlogs 信息和角色标记。 - 强烈建议加
AS COMPRESSED BACKUPSET：2TB 以上库不压缩，备份传输和恢复耗时翻倍，且容易因 NFS 挂载超时中断。 - format 路径避免含空格或特殊字符，RMAN 在某些 Oracle 版本（如 11.2.0.4）对路径解析异常，导致
CATALOG START WITH找不到备份片。
备库恢复时顺序错一步就卡死
不是“restore → recover”两步完事。真实流程有严格依赖：
- 先停 MRP：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL - shutdown immediate → startup nomount →
RESTORE STANDBY CONTROLFILE FROM '/path/standby_ctrl.bak' - startup mount（此时控制文件已是 standby 角色）→
CATALOG START WITH '/backup/path/' - 检查是否新增数据文件：
SELECT NAME FROM V$DATAFILE_HEADER WHERE CREATION_CHANGE# > <scn>。若有，必须临时设STANDBY_FILE_MANAGEMENT=MANUAL，手工ALTER DATABASE CREATE DATAFILE，再切回AUTO - 最后才跑：
RECOVER DATABASE NOREDO。注意不是RECOVER DATABASE—— 后者会尝试应用归档，而你正缺归档。
恢复后验证不能只看 OPEN READ ONLY
备库 ALTER DATABASE OPEN READ ONLY 成功，不代表同步已恢复。必须确认三件事：
- 启动 MRP：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT，然后立刻查V$MANAGED_STANDBY确认PROCESS = 'MRP0'且STATUS = 'APPLYING_LOG' - 对比主备最新日志序列：
SELECT THREAD#, MAX(SEQUENCE#) FROM V$ARCHIVED_LOG GROUP BY THREAD#，主库和备库的差值应 ≤ 1（切换延迟正常） - 查
V$DATAGUARD_STATS的apply lag和transport lag，单位是秒，不是空值或 “+00 00:00:00” 才算稳住
最容易被忽略的是：增量恢复后首次 SWITCH LOGFILE，主库新产生的归档必须能自动传到备库并被 MRP 拉取。如果仍报 FAL 错误，大概率是主库 LOG_ARCHIVE_DEST_2 的 VALID_FOR 配置没覆盖 standby_role + archive_log，或者备库监听未注册服务名。
