明确信号是MRP0未运行、v$archived_log.applied='NO'堆积或v$archive_gap非空；须先查GAP真伪，再据归档是否存在分FAL自动修复或11g增量备份修复（备库取SCN→主库增量备份→传控件与备份→备库挂载→注册→RECOVER DATABASE NOREDO→重启应用）。
主备库不同步不是配置问题，而是状态异常的明确信号——MRP0进程没在持续运行、v$archived_log.applied='NO'的归档堆积、v$archive_gap返回非空结果，三者任一出现，就得立刻干预。
确认 GAP 是否真实存在
别只看 v$log 的 sequence# 最大值是否一致。真问题藏在归档日志链路上：
- 在备库查
SELECT * FROM V$ARCHIVE_GAP;—— 返回任意行就说明 GAP 存在 - 查
SELECT thread#, sequence#, applied FROM v$archived_log WHERE applied = 'NO' ORDER BY sequence#，看未应用日志是否连续 - 执行
SELECT process, status, sequence# FROM v$managed_standby WHERE process = 'MRP0'，如果没返回或status是WAIT_FOR_LOG，MRP0实际已退出 - 立刻翻备库
alert.log尾部，搜ORA-01092、control file version mismatch、incompatible database version—— 这些比 GAP 更优先处理
区分 GAP 成因：归档丢失 or 版本不匹配
这是修复路径的分水岭。错判会导致反复失败：
- 如果
v$archive_gap有结果，且主库上对应sequence#的归档文件物理存在（ls -l $ORACLE_HOME/dbs/arch* | grep <seq></seq>或查dba_hist_archive_dest），说明是传输/应用卡点，走 FAL 或手动拷贝 - 如果主库上查不到对应归档（
SELECT name FROM v$archived_log WHERE sequence# = <gap_seq> AND deleted = 'NO'</gap_seq>返回空），就是归档丢失，必须用增量备份修复 - 如果
MRP0启动即退出、alert.log出现版本类报错，立刻停所有恢复操作，先比对SELECT banner FROM v$version WHERE banner LIKE 'Oracle%'和$ORACLE_HOME/OPatch/opatch lsinventory -detail—— 小版本号（如11.2.0.4.190115）和 PSU 补丁包必须一字不差
Oracle 11g 增量备份修复 GAP（归档丢失场景）
这是最常踩坑的操作环节，顺序和细节决定成败：
- 在备库执行
SELECT current_scn FROM v$database;记下 SCN 值（例如12345678） - 主库用 RMAN 执行：
BACKUP INCREMENTAL FROM SCN 12345678 DATABASE FORMAT '/tmp/incr_%U.bkp';
- 把备份集和主库最新 standby controlfile（
ALTER DATABASE CREATE STANDBY CONTROLFILE AS '/tmp/stdby.ctl';）一起拷到备库相同目录 - 备库
SHUTDOWN IMMEDIATE→STARTUP NOMOUNT→RESTORE STANDBY CONTROLFILE FROM '/tmp/stdby.ctl'→ALTER DATABASE MOUNT - 注册备份：
CATALOG START WITH '/tmp/incr_';，然后取消当前恢复：ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; - 关键一步：
RECOVER DATABASE NOREDO;（注意不是RECOVER DATABASE USING BACKUPSET） - 最后重启应用：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;
Oracle 12c+ 使用 RECOVER ... FROM SERVICE
省去拷贝备份集步骤，但依赖网络和 TNS 配置精度：
- 确保主库 TNS 名称（如
orcl_primary）在备库tnsnames.ora中存在，且包含(UR=A)参数（否则 RMAN 连接会超时） - 备库
SHUTDOWN IMMEDIATE→STARTUP NOMOUNT - 执行：
RMAN TARGET /<br>RESTORE STANDBY CONTROLFILE FROM SERVICE orcl_primary;<br>ALTER DATABASE MOUNT;
- 检查是否有新增数据文件（
SELECT file# FROM v$datafile WHERE creation_change# >= <min_scn_from_v></min_scn_from_v>），若有，需提前在备库创建对应目录并ALTER DATABASE CREATE DATAFILE - 执行：
RECOVER DATABASE FROM SERVICE orcl_primary NOREDO USING COMPRESSED BACKUPSET;
（NOREDO必须加，否则报错） - 启动应用：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;
真正卡住的往往不是命令本身，而是 MRP0 启动后几秒内静默退出——这时别 retry，先看 alert.log 第一行错误；还有人忽略 STANDBY_FILE_MANAGEMENT=MANUAL 下重命名 redo/temp 文件的必要性，导致 RECOVER 报 ORA-01111。
