mrp进程未启动或卡在wait_for_gap时，首要确认其是否运行：查v$managed_standby无mrp0记录或状态非applying_log，需手动启动并确保备库处于mount或read only with apply状态。
MRP进程没启动或卡在WAIT_FOR_GAP状态
备库归档日志已传到，但数据就是不应用，第一反应不是网络或权限问题，而是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解析失败），本质都是认证或连通性断了。
-
ORA-16191几乎全是密码文件问题：主备库SYS密码不一致，或备库缺少orapw<sid></sid>文件，或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里留痕。这是最隐蔽的同步中断原因。
- 必须主动查：
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
真正棘手的从来不是单点故障，而是多个条件叠加：比如MRP卡在GAP上，同时备库又缺空间，而你只盯着TNS连通性调了一整天。排查时别跳步，按“传输→接收→应用”三层顺序验证，每层都得看到明确证据，而不是凭感觉猜。
