应查主备库归档序列号差值或v$archive_gap视图确认断点；停mrp进程后再备份；scn须取自备库v$database.checkpoint_change#；恢复后需重建备用控制文件并校验归档路径。
备库报 ora-16055 或 gap detected，怎么确认当前日志断点？
先别急着备份，得知道断在哪。最直接的方式是查主库和备库的归档序列号是否对得上：
- 在主库执行：
SELECT THREAD#, MAX(SEQUENCE#) FROM V$ARCHIVED_LOG GROUP BY THREAD#; - 在备库执行：
SELECT THREAD#, MAX(SEQUENCE#) FROM V$ARCHIVED_LOG WHERE APPLIED='YES' GROUP BY THREAD#; - 对比两者的
SEQUENCE#差值，就是 Gap 大小；如果备库没这条日志，V$ARCHIVED_LOG里可能压根没记录，这时候得看V$ARCHIVE_GAP
V$ARCHIVE_GAP 是专门干这事的——它只返回“主库有、备库缺失”的归档范围，但注意：它只反映最近一次 MRP 进程扫描后的结果，不是实时的。如果 MRP 挂了或没启动，这个视图可能为空。
用 RMAN 做增量备份前，必须停掉备库的恢复进程吗？
必须停。MRP（Managed Recovery Process）会持续尝试应用日志，如果你一边增量恢复、一边它还在读控制文件找日志，轻则报 ORA-19909（datafile belongs to a standby database），重则导致控制文件状态错乱，后续 RECOVER DATABASE NOREDO 失败。
- 停 MRP：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; - 确认已停：
SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY WHERE PROCESS = 'MRP0';—— 应该返回空或STATUS = 'WAIT_FOR_LOG'（说明已退出） - 别漏掉
SQL> RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;这种旧命令残留，它们可能让 MRP 静默重启
BACKUP INCREMENTAL FROM SCN 的 SCN 怎么取才不丢数据？
SCN 必须取自备库当前的 checkpoint_change#，不能取主库的 current SCN，也不能手敲一个“大概值”。取错会导致增量备份包含未提交事务、或者跳过部分已应用日志，最终 RECOVER DATABASE NOREDO 报 ORA-01152（file not restored from backup）。
- 查备库 SCN：
SELECT CHECKPOINT_CHANGE# FROM V$DATABASE; - RMAN 中执行：
BACKUP INCREMENTAL FROM SCN <code>xxxDATABASE FORMAT '/path/incr_%U.bkp' TAG 'DG_INCR_REPAIR'; - 备份完立刻传到备库主机（别用 NFS 挂载路径，避免权限/锁问题），且确保
DB_RECOVERY_FILE_DEST不在同一个磁盘分区——否则恢复时可能因空间不足失败
恢复增量备份后，为什么 ALTER DATABASE RECOVER MANAGED STANDBY DATABASE 还卡住？
常见原因是控制文件没更新到最新状态，或者归档日志路径配置不一致。增量恢复只是把数据文件拉平，但备库的控制文件仍认为自己“落后于主库”，MRP 启动后第一件事就是去找它以为缺失的日志——而那些日志其实已经被增量覆盖了，所以卡在 waiting for gap sequence。
- 恢复完必须重建备用控制文件：
ALTER DATABASE CREATE STANDBY CONTROLFILE AS '/tmp/stby_ctl.ctl';，再替换原控制文件并重启实例（STARTUP MOUNT） - 检查
LOG_ARCHIVE_DEST_2是否指向主库正确服务名，且VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE)—— 错配会导致 MRP 误判日志来源 - 启动 MRP 前加
USING CURRENT LOGFILE：避免它从旧日志头开始扫，ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;
Gap 修复不是单次操作的事，尤其在高并发主库上，备份+传输+恢复窗口内可能又产生新 Gap。真正稳的做法是：增量备份完成后，立刻在主库手动切换一次日志（ALTER SYSTEM SWITCH LOGFILE;），再确认备库是否能连续应用——这一步很多人跳过，结果第二天发现又断了。
