当 MRP 进程未启动，或长时间停留在 WAIT_FOR_GAP 状态时，第一步要先确认它是否真的在运行。可通过查看 v$managed_standby 判断：如果没有 MRP0 记录，或者状态不是 APPLYING_LOG，就需要手动启动恢复进程，同时确保备库处于 MOUNT 或 READ ONLY WITH APPLY 状态。

MRP进程没启动或卡在WAIT_FOR_GAP状态

很多 Oracle Data Guard 主备不同步问题，表面上看是归档日志已经传到备库，但数据始终没有继续应用。遇到这种情况，不要一开始就怀疑网络或权限，首先应重点检查 MRP 进程是否根本没有启动。如果执行V$MANAGED_STANDBY后查不到MRP0记录，或者其状态显示为WAIT_FOR_GAP，通常说明日志应用已经卡在缺失归档的位置。

• 确认 MRP 是否运行：SELECT PROCESS, STATUS, SEQUENCE# FROM V$MANAGED_STANDBY WHERE PROCESS IN ('MRP0', 'MRP');
• 如果没有返回结果，或 STATUS 不是APPLYING_LOG，可手动启动：ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;
• 注意：备库必须处于MOUNT或READ ONLY WITH APPLY状态，处于OPEN READ ONLY时 MRP 不会执行日志应用

主库归档传输失败报ORA-16191或ORA-12154

如果主库归档日志根本没有成功发送到备库，那么后续自然无法应用。常见报错包括ORA-16191（主库 LNS 无法登录备库）和ORA-12154（TNS 名称解析失败），这类 Oracle 日志传输异常，本质上大多与认证配置或网络连通性有关。

• ORA-16191通常都是密码文件问题：例如主备库SYS密码不一致、备库缺少orapw文件，或REMOTE_LOGIN_PASSWORDFILE没有设置为EXCLUSIVE或SHARED
• ORA-12154则多为 TNS 配置异常：主库log_archive_dest_2中配置的 service_name 在tnsnames.ora中不存在，或者监听未启动、防火墙拦截了端口
• 检查传输状态：SELECT DEST_NAME, STATUS, ERROR FROM V$ARCHIVE_DEST WHERE DEST_ID = 2;，其中 ERROR 列通常可以直接定位问题根因

备库存在ARCHIVE_GAP但没被发现

有些情况下，归档日志虽然传到了备库，但中间缺失了部分序列，MRP 就会悄无声息地卡住——既不明显报错，也不会继续推进，告警日志里也未必第一时间体现，只会在V$ARCHIVE_GAP中留下线索。这往往是 Oracle Data Guard 同步中断里最隐蔽、也最容易忽视的一类原因。

• 必须主动检查：SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;
• 如果有返回结果，就说明确实存在归档缺口；如果没有结果，也不代表绝对正常，还需要进一步核对V$ARCHIVED_LOG中APPLIED='YES'的最大SEQUENCE#是否仍明显落后于主库
• 缺口修复不能只靠等待自动补齐：应到主库查找对应SEQUENCE#的归档日志路径，手动复制到备库后，再通过ALTER DATABASE REGISTER PHYSICAL LOGFILE完成注册

STANDBY_FILE_MANAGEMENT=MANUAL导致文件缺失

当主库新增表空间或数据文件时，如果备库磁盘空间不足，或者参数设置为MANUAL，就可能生成类似UNNAMED00135这样的占位文件，随后日志应用会直接失败，并报出FILE MISSING错误。这也是导致备库应用中断的典型原因之一。

• 检查备库缺失文件：SELECT FILE#, NAME FROM V$RECOVER_FILE WHERE ERROR = 'FILE MISSING';
• 确认参数设置：SHOW PARAMETER STANDBY_FILE_MANAGEMENT，生产环境下通常必须保持为AUTO
• 临时处理方式：ALTER DATABASE CREATE DATAFILE '/path/to/UNNAMED00135' AS '/real/path/file01.dbf';，但这只是应急修复，根本方案仍是及时扩容并将参数切回 AUTO

真正复杂的 Oracle 主备日志不同步，往往不是单一故障引起，而是多个条件同时叠加。例如 MRP 卡在 GAP 上的同时，备库又恰好磁盘空间不足，如果只盯着 TNS 连通性排查，可能会白白耗费大量时间。正确的排查思路不要跳步，应按照“传输→接收→应用”的顺序逐层验证，每一步都要看到明确证据，而不是依靠经验或感觉判断。