MRP0状态非APPLYING_LOG或sequence#长期不增，说明应用已卡住；需查v$managed_standby确认状态，结合transport_lag与apply_lag定位主库传输或备库I/O瓶颈，并用SCN差值校验真实延迟。
主库归档生成太快，备库MRP进程根本追不上——这不是配置漏了，而是I/O、网络或参数没对齐的综合结果。
查MRP0是否真在APPLYING_LOG，别信ps aux
很多人看到ps aux | grep mrp有进程就以为日志在应用，其实MRP可能早就在WAIT_FOR_LOG或NOT ACTIVE状态静默挂起。必须查v$managed_standby：
SELECT process, status, sequence#, thread# FROM v$managed_standby WHERE process = 'MRP0';
如果status不是APPLYING_LOG，或者sequence#长时间不递增，说明应用已卡住。常见原因包括：
-
UNNAMED数据文件未手动创建（STANDBY_FILE_MANAGEMENT=MANUAL时必现） - 备库
DB_RECOVERY_FILE_DEST空间满，导致归档无法写入 - 控制文件损坏或SCN异常，MRP启动后立即abort但不报错
transport lag > apply lag？问题出在主库发送端
如果v$dataguard_stats里transport lag远大于apply lag，说明日志根本没传到备库——别急着优化备库I/O，先盯主库的LOG_ARCHIVE_DEST_2配置：
- 确认是否用了
LGWR ASYNC但漏配NET_TIMEOUT=30 REOPEN=60，默认180秒超时会让短暂抖动反复重传 - 检查主库
LOG_BUFFER是否≥100MB（OLTP场景下太小会放大网络等待） - 用
tnsping和ping -s 1472测MTU级连通性，丢包或高延迟会直接拖垮LGWR异步传输
MRP CPU高但apply lag不降？大概率是I/O或解压瓶颈
MRP进程本身不直接读磁盘，它调度SQL Apply线程处理归档；但若这些线程被卡住，就会表现为CPU占用高、sequence#不动：
- 备库
standby redo log路径落在NFS或低IOPS云盘上，写入延迟高 - 归档未压缩（
LOG_ARCHIVE_DEST_2没加COMPRESSION=ENABLE），MRP解压耗时长 -
STANDBY_FILE_MANAGEMENT=AUTO开着，每次应用日志都触发字典查询，额外开销不可忽视 - 备库
DB_CREATE_FILE_DEST和DB_RECOVERY_FILE_DEST指向同一块慢盘，争用严重
SCN差值比V$DATAGUARD_STATS更准，但得立刻执行
v$dataguard_stats里的apply lag是Oracle估算值，经常滞后甚至不准。真实延迟必须靠SCN比对：
主库执行：SELECT DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER FROM DUAL;
备库1秒内执行同样语句，然后用差值除以每秒SCN增速（通常1~5万/秒）估算秒级延迟。
如果备库SCN长时间不涨，且v$managed_standby中MRP0的PROCESS显示UNKNOWN，赶紧去alert.log搜ORA-16047或ORA-16191——这类错误往往只写日志，不抛给SQL*Plus。
