备库MRP进程卡在“WAIT_FOR_GAP”或报“UNNAMED”错误，主因是FRA空间100%满，RMAN清理需加FORCE参数并确认归档连续性，否则无法启动重做应用。
备库同步挂起，mrp进程卡在“wait_for_gap”或反复报“unnamed”文件错误？大概率不是网络或日志传输问题，而是备库磁盘空间不足，导致归档日志堆积、重做应用失败。rman自动清理过期归档是最快见效的干预手段，但必须配合路径确认和保留策略调整，否则清理完立刻又满。
为什么RMAN清理归档后MRP还是不启动？
常见现象是执行了DELETE ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-1'，V$ARCHIVED_LOG里旧日志确实没了，但SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY中MRP仍为WAIT_FOR_GAP，甚至ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL都卡住。
- 根本原因：备库的
DB_RECOVERY_FILE_DEST（即FRA）已100%满，RMAN清理只删了归档日志，但FRA里还堆着未应用的归档、控制文件快照、甚至临时备份片段，MRP无法写入新状态文件，直接拒绝启动 - 必须先查清FRA真实占用：
SELECT * FROM V$RECOVERY_FILE_DEST，重点关注SPACE_LIMIT和SPACE_USED，别只信df -h——FRA可能在/u01/fast_recovery_area，而df -h /u01显示还有空间，但FRA内部已被占满 - 清理命令要加
FORCE参数：DELETE FORCE ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-1'，否则RMAN遇到正在被MRP读取的归档会跳过，白忙活
如何安全清理FRA而不中断后续同步？
不能无脑CROSSCHECK ARCHIVELOG ALL + DELETE EXPIRED，这会误删主库还没传过来的归档，导致GAP不可补。关键在“按需保留”：
- 先确认主备归档序列连续：
SELECT THREAD#, MAX(SEQUENCE#) FROM V$ARCHIVED_LOG WHERE DEST_ID=1 GROUP BY THREAD#（主库），对比备库DEST_ID=2的结果，差值超过5就说明有GAP，此时清理必须保守 - 执行清理前，强制刷新归档状态：
ALTER SYSTEM ARCHIVE LOG CURRENT（主库），再等1分钟，确保最新归档已传到备库 - 推荐清理语句：
RMAN TARGET / CATALOG rman/rman@rcat ——保留最近12小时归档，足够覆盖网络延迟和人工干预窗口
清理后MRP仍不恢复？检查STANDBY_FILE_MANAGEMENT和DB_FILE_NAME_CONVERT
即使FRA腾出空间，MRP也可能因文件路径转换失败继续卡在UNNAMED。这是备库磁盘空间不足引发的次生故障：
- 确认参数生效：
SHOW PARAMETER STANDBY_FILE_MANAGEMENT必须是AUTO，若为MANUAL，MRP不会尝试自动建数据文件，只能手动ALTER DATABASE CREATE DATAFILE ... AS ... - 检查路径映射：
SHOW PARAMETER DB_FILE_NAME_CONVERT输出的源路径（主库）和目标路径（备库）是否指向真实存在的、有写权限的目录？例如主库路径是'+DATA/orcl/datafile/，备库目标却配成'/u01/oradata/stdby/'，而该目录所在文件系统只剩200MB，MRP创建文件时失败，就会生成UNNAMED00012并停摆 - 临时绕过路径问题：
ALTER SYSTEM SET DB_FILE_NAME_CONVERT='' SCOPE=MEMORY（仅当前实例），让MRP用默认路径创建文件，等同步追平后再改回正确映射
真正容易被忽略的是：FRA清理后，MRP不会自动重启，必须显式执行ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION。而且首次启动时会扫描所有归档日志头，如果FRA刚清理完还有大量碎片文件，这个扫描可能耗时几分钟，期间STATUS显示APPLYING_LOG但SEQ#不增长，别误判为卡死。
