根本原因是主库日志生成节奏超过备库整条链路吞吐能力；MRP0状态为APPLYING_LOG但SEQUENCE#长期不动，常见于SRL磁盘I/O阻塞、standby redo log组数或尺寸不足、未启用实时应用、STANDBY_FILE_MANAGEMENT=AUTO引发字典查询争用，或主库传输配置缺失LGWR ASYNC/NET_TIMEOUT导致日志未发全。
根本原因不是“备库慢”，而是主库日志生成节奏压过了备库的接收、解压、I/O、SQL回放整条链路的吞吐能力。 单看MRP进程状态为APPLYING_LOG不等于它真在有效推进——它可能卡在I/O、锁争用、单线程瓶颈或standby redo log资源枯竭上。
为什么MRP0状态正常但SEQUENCE#长期不动
常见于以下几种真实场景：
-
v$managed_standby中MRP0的STATUS是APPLYING_LOG，但SEQUENCE#和BLOCK#几分钟无变化：大概率是备库redo日志路径落在NFS/低IOPS云盘，或DB_RECOVERY_FILE_DEST所在磁盘写入延迟高，MRP读取standby redo时被阻塞 - 查
v$standby_log发现所有组STATUS为ACTIVE，且v$archive_gap为空：说明日志已传到，但没空闲SRL接收新日志——根本原因是standby redo log组数太少或尺寸小于主库最大online redo log（比如主库在线日志200MB，备库SRL只有100MB） - 备库
RECOVERY_MODE返回MANAGED STANDBY而非MANAGED REAL TIME APPLY：说明没启用实时应用，MRP只能等RFS把归档写完再启动应用，天然存在分钟级排队窗口
STANDBY_FILE_MANAGEMENT=AUTO会拖慢MRP吗
会，而且影响隐蔽。该参数开启后，MRP每应用一个归档日志，都要触发一次数据字典查询（比如检查是否需要自动创建新数据文件），在高并发日志流下会放大latch争用。尤其当备库处于READ ONLY WITH APPLY模式时，这种额外开销更明显。
- 除非业务明确需要自动添加数据文件（如频繁建表空间+数据文件），否则建议设为
MANUAL - 修改后无需重启实例：
ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=MANUAL; - 改完立刻查
v$session_event中library cache lock和row cache lock等待是否下降
并行应用能解决速度跟不上吗
能，但前提是瓶颈真在SQL回放层，而不是I/O或内存。Oracle 12c+默认仍是单线程MRP，遇到大事务或批量DML极易积压。
- 先确认是否值得并行：查
v$logstdby_transaction，若STATE长时间为APPLYING且APPLIED_SCN增长缓慢，说明是回放瓶颈 - 启用并行需两步：
ALTER SYSTEM SET parallel_execution_message_size=8192;+ 实例重启后加参数parallel_recovery_target=4（从4起步，别直接设16） - 注意隐含参数
_maximum_parallel_apply_servers慎调——它不控制实际并行度，只设上限；超CPU核心数反而引发parallel recovery coordinatorlatch争用
最常被忽略的一点：LOG_ARCHIVE_DEST_2里漏了LGWR ASYNC或NET_TIMEOUT，导致主库ARCH进程被网络抖动反复阻塞，日志还没发全，备库MRP就只能干等。这不是备库的问题，是主库传输配置没兜住底。
