备库MRP进程卡在APPLYING_LOG状态且delay_mins持续增长，表明日志解压、重做应用或I/O写入存在瓶颈；需检查磁盘I/O、STANDBY_FILE_MANAGEMENT参数、主备库等待事件及归档空间。
查备库MRP进程是否卡在 APPLYING_LOG 状态
备库延迟不降、APPLYING_LOG在 v$managed_standby 里长期存在，是应用层瓶颈的典型信号。这不是网络或传输问题，而是MRP进程本身被拖住。
执行：
SELECT process, status, sequence#, blocks, block#, delay_mins FROM v$managed_standby WHERE process = 'MRP0';若
status 是 APPLYING_LOG 且 delay_mins 持续增长（>5），说明日志解压、重做应用或I/O写入已跟不上节奏。
- 检查备库
DB_RECOVERY_FILE_DEST所在磁盘I/O：用iostat -x 1看%util是否持续 >90%，await是否 >20ms - 确认归档日志路径是否落在慢设备上（如NFS、低IOPS云盘）——MRP必须读归档+写redo+更新控制文件，三重I/O压力下任何一环都可能成瓶颈
- 查
v$session_event中该MRP会话的等待事件：若高频出现db file sequential write或log file parallel write，说明写入目标（如standby redo log）所在磁盘响应慢
验证STANDBY_FILE_MANAGEMENT是否引入额外开销
STANDBY_FILE_MANAGEMENT=AUTO 在非必要场景下会显著拖慢MRP，因为它每次应用日志前都要查数据字典确认文件是否存在、是否需自动创建，尤其在频繁DDL的主库环境中。
执行：
SHOW PARAMETER STANDBY_FILE_MANAGEMENT;若返回
AUTO，且备库无自动加数据文件需求（如只读报表库），应立即关闭：
ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=MANUAL SCOPE=BOTH;- 重启MRP（
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;后再启动） - 观察
v$active_session_history中MRP会话的sql_id是否从字典查询类SQL（如select obj#,type#,ctime,mtime,stime...）切换为重做应用类操作
注意：AUTO 不是“省事开关”，而是高开销开关；除非主库确有动态增删数据文件行为，否则一律设为 MANUAL。
盯紧 log file sync 和 LGWR-LNS wait on channel 的关联性
主库 log file sync 突然升高，且源头会话等待 LGWR-LNS wait on channel，说明DG同步链路已在反向拖累主库事务提交——这常被误判为I/O问题，实则是备库应用太慢导致LNS无法及时确认。
查证步骤：
- 在主库跑：
SELECT event, COUNT(*) FROM v$active_session_history WHERE sample_time > SYSDATE-1/24 GROUP BY event ORDER BY 2 DESC;
若LGWR-LNS wait on channel进入Top 3，基本锁定备库端阻塞 - 检查主库
LOG_ARCHIVE_DEST_2是否用了AFFIRM：若有，备库写入standby redo log失败或超时，会强制主库LGWR等待 - 对比主库
v$dataguard_stats中transport lag和apply lag：若前者≈0但后者持续增大，问题纯在备库；若两者同步增大，说明LNS发送也卡住了（可能是网络或主库LGWR压力大）
此时调大主库 LOG_BUFFER（≥100MB）可缓解LGWR频繁刷盘放大网络等待的影响，但治标不治本——备库I/O或MRP配置才是根因。
确认归档空间满或GAP是否触发隐式阻塞
备库 DB_RECOVERY_FILE_DEST 空间满，或存在未处理的GAP，会导致ARCH进程挂起在 waiting for archive log，进而让MRP失去新日志输入，表面看是“没东西可应用”，实际是源头断供。
必须一次性验清三项：
- 查空间：
SELECT SPACE_USED/SPACE_LIMIT FROM v$recovery_file_dest;
若 >0.95，立刻清理或扩容；不能只靠RMAN策略，要结合applied='YES'+COMPLETION_TIME 手动删 - 查GAP：
SELECT * FROM v$archive_gap;
若有记录，说明主库有归档未传到备库，需手工拷贝并注册（ALTER DATABASE REGISTER PHYSICAL LOGFILE 'xxx'） - 查MRP状态：
SELECT process, status FROM v$managed_standby WHERE process IN ('MRP0','RFS');若MRP是WAIT_FOR_LOG但RFS状态异常（如IDLE或长时间CONNECTED却无新sequence#），大概率是归档路径不可写或监听中断
这些状态不会直接报错，但会让MRP“静默饥饿”——它不报错，只是停转。排查时最容易漏掉的就是这种“无声故障”。
