MRP单线程撑不住高并发日志应用，因其仅协调、不解析redo，高负载时成调度瓶颈；启用并行需满足版本≥12.1、ADG启用、COMPATIBLE≥12.1；ALTER DATABASE RECOVER PARALLEL 4实际启1主+3子MRP，受隐含参数限制；STANDBY_FILE_MANAGEMENT=AUTO和I/O路径不当常导致并行失效。
为什么MRP单线程撑不住高并发日志应用
物理备库默认只用一个MRP（Managed Recovery Process）协调所有日志应用，它本身不直接解析redo，而是分发任务给后台的APPLY线程。当主库OLTP压力大、归档频繁、或备库I/O慢时，MRP会成为瓶颈：V$MANAGED_STANDBY里看到大量APPLYING_LOG但apply lag持续上涨，top里MRP进程CPU高但磁盘IO利用率低——说明不是存储慢，是调度不过来。
启用并行恢复前必须确认的三件事
Oracle不会自动开启多MRP，必须手动配置且满足前提：
- 数据库版本 ≥ 12.1（11g不支持多MRP，强行设
PARALLEL参数无效） - 备库已启用Active Data Guard：
SELECT database_role, open_mode FROM v$database返回PHYSICAL STANDBY和READ ONLY WITH APPLY - 主库
COMPATIBLE参数 ≥ 12.1（否则ALTER DATABASE RECOVER ... PARALLEL报ORA-16025）
ALTER DATABASE RECOVER PARALLEL 4的实际效果与限制
执行ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE PARALLEL 4 DISCONNECT后，并非简单启动4个MRP。Oracle实际行为是：
- 保留1个主MRP负责协调和日志轮转
- 额外启动3个
MRPn子进程（n=1~3），每个独立处理不同redo thread或SCN区间 - 并行度上限受
_maximum_parallel_apply_servers隐含参数控制，默认值为CPU_COUNT × 2，但生产环境建议不超过8 - 若备库redo日志路径在NFS或低IOPS云盘上，盲目开高并行反而导致I/O争用，
IO_WAIT在V$SYSTEM_EVENT中飙升
验证是否生效：SELECT process, status, sequence# FROM v$managed_standby WHERE process LIKE 'MRP%'应看到4行记录（MRP0 + MRP1~MRP3）。
比PARALLEL更关键的是STANDBY_FILE_MANAGEMENT和I/O路径
很多团队开了PARELLEL 8却没改善延迟，真正卡点常在文件管理环节：
- 若
STANDBY_FILE_MANAGEMENT=AUTO，每次日志应用前MRP会触发字典查询判断是否要创建新数据文件，这个操作串行阻塞所有并行线程——临时切MANUAL再手工补文件，延迟立降 -
DB_RECOVERY_FILE_DEST和DB_CREATE_FILE_DEST必须指向本地SSD，不能共用同一块盘；若归档解压慢（尤其未启用LOG_ARCHIVE_DEST_n的COMPRESSION=ENABLE），并行线程全在等解压完成 - 检查
V$ARCHIVE_DEST_STATUS中STATUS为VALID且ERROR为空，否则并行线程会因传输失败反复重试
并行恢复不是“开越多越好”，它放大底层缺陷。真正决定延迟下限的，是单个日志块从网络接收、解压、校验、写入磁盘、更新SCN这一整条链路里最慢的那个环节。
