备库不同步八成因归档未传输、未接收或无法应用，应先查v$archive_gap确认缺口，再查v$managed_standby验证mrp是否真在applying_log，最后按序处理unnamed文件及手动注册缺失归档。
备库不同步，八成是归档日志没传过去、没收到、或收到了但应用不了——先别急着重建，90% 的问题能靠几条 sql 和几个关键状态查清楚。
查 v$archive_gap 确认有没有归档缺口
这是最直接的判断依据。备库上执行：
SELECT * FROM v$archive_gap;
如果有记录，说明主库某段归档日志根本没传到备库（传输中断），不是应用慢的问题。常见原因包括：
-
LOG_ARCHIVE_DEST_2配置里VALID_FOR或SYNC/ASYNC模式和主库不匹配 - 主库
ARCH进程卡住（查V$ARCHIVE_PROCESSES中STATE是否为WAIT_FOR_LOG） - 网络不通或防火墙拦截了
LGWR连接（尤其用LGWR ASYNC时） - 主库归档路径满，导致归档失败，后续日志无法生成和传输
看 v$managed_standby 判断 MRP 是否真在跑
MRP（Managed Recovery Process）不报错也不退出，只是静默 halt——这是最坑的假同步现象。执行：
SELECT process, status, sequence# FROM v$managed_standby WHERE process = 'MRP0';
如果 status 是 APPLYING_LOG 才算真在干活；如果是 WAIT_FOR_LOG 或 NOT ACTIVE，说明它早就停了。停因通常有：
- 遇到
UNNAMED数据文件（ORA-01111），MRP 自动挂起等待人工干预 - 控制文件时间戳异常，或备库
DB_NAME/DB_UNIQUE_NAME和主库不一致 - 归档日志校验失败（比如手动拷贝时文件大小或时间戳被改过）
别只依赖 ps aux | grep mrp，这个命令可能显示进程还在，但内部早已 halt。
用 LIST ARCHIVELOG 定位缺失归档范围
一旦确认有 gap，去主库查具体缺哪几段：
LIST ARCHIVELOG FROM SEQUENCE <code>low_seq</code> UNTIL SEQUENCE <code>high_seq</code> THREAD <code>thread_num</code>;
注意：low_seq 和 high_seq 要从 v$archive_gap 输出里取，thread_num 一般是 1（单实例）或对应 RAC 线程号。查出来后：
- 确认这些归档是否真在主库
LOG_ARCHIVE_DEST_1目录下存在 - 若存在，用
scp或rsync拷到备库相同路径（路径必须和LOG_ARCHIVE_DEST_2一致） - 拷完别直接
RECOVER，先手动注册：ALTER DATABASE REGISTER PHYSICAL LOGFILE '<code>full_path_to_arch'; - 再执行
RECOVER AUTOMATIC STANDBY DATABASE;
手动注册能绕过 RFS 进程对文件时间戳、大小的严格校验，避免因微小差异被拒收。
检查 standby_file_management 是否导致 UNNAMED 文件堆积
当主库新增数据文件而备库空间不足或路径转换失败时，Oracle 会生成 UNNAMED00xxx 占位文件，MRP 就卡在这儿不动。查法：
SELECT file#, name FROM v$datafile WHERE name LIKE '%UNNAMED%';
若结果非空，说明这是根因。修复步骤必须按顺序来：
- 先停 MRP：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; - 切手动模式：
ALTER SYSTEM SET standby_file_management=MANUAL SCOPE=BOTH; - 用
ALTER DATABASE CREATE DATAFILE '<code>/path/to/UNNAMED00xxx' AS '/correct/path/file.dbf'; 创建真实文件 - 权限、磁盘空间、路径可写性，三者缺一不可——曾经有案例恢复后仍失败，就因为
oracle用户对目标目录无写权限 - 完成后切回自动：
ALTER SYSTEM SET standby_file_management=AUTO SCOPE=BOTH;
这一步最容易漏掉的是“切回 AUTO”，不切回去，下次主库加文件还会重蹈覆辙。
