MRP并行度由隐藏参数_recovery_parallelism控制，其默认值为0（Oracle自动管理），设为正整数可强制指定并行进程数，但实际效果受ASM磁盘组STRIPE_COLUMN值及存储布局制约。
MRP并行度由哪个参数控制
oracle
data guard中，
（managed recovery process）本身**没有直接的“并行度参数”**。所谓“并行恢复”，实际由隐式启用的
和底层asm磁盘组条带能力共同决定，而非像sql那样通过
提示显式指定。
真正起作用的是两个关键机制：
：隐藏参数，默认值为0（由Oracle自动计算），设为正整数会强制启用固定数量的并行恢复进程（如
）
ASM磁盘组的
值：它决定了该磁盘组物理上能支撑多少并发IO路径；
越小，并行上限越低——例如值为2的磁盘组，强行配8个恢复进程只会造成争抢
查当前ASM条带信息：
为什么调高并行数反而变慢
常见错误是看到日志应用延迟大，就盲目在spfile里加
甚至16，结果
等待飙升、
频繁出现。
根本原因有三：
底层ASM磁盘组未做条带优化（比如EXTERNAL REDUNDANCY + 单块SAS盘），
为1，物理上无法承载高并发写入
归档路径（
）和数据文件落在同一磁盘组，MRP一边读归档、一边写数据块，随机读+顺序写混在同一IO队列
未关闭
或设为0，导致MRP被频繁打断重调度，丧失连续IO吞吐
验证是否踩坑：
若返回值为
，且观察到大量
等待（占比＞10%），优先调高至
再评估并行度
oracle知识库
oracle知识库下载
下载
安全调整MRP并行度的操作步骤
调整不是改一个参数就完事，必须配合存储布局与归档策略同步优化：
确认归档路径与数据文件已分离：用
和
交叉比对，确保
指向独立磁盘组
停MRP：
设并行度（仅当
时才建议≥4）：
重启数据库使参数生效（非仅重启MRP）
重新启动MRP：
注意：
是隐藏参数，修改后必须重启实例；设为0表示交还控制权给Oracle自动管理，多数场景下反而是更稳的选择
如何判断并行调整是否真正生效
不能只看参数值，要从进程和等待事件两个层面验证：
查MRP相关进程数：
正常应看到多个
、
等，而非仅
检查IO等待分布：
若
平均等待时间仍＞10ms，或
持续＞5ms，说明底层存储仍是瓶颈，加并行无意义
对比AWR中
部分的“Applied Redo Rate (MB/sec)”指标，提升应体现在该数值上，而非单纯进程数增加
最常被忽略的一点：即使
足够，如果备库归档目录所在磁盘组使用了
且只有1块盘，那再多的MRP进程也跑不满带宽——并行度的天花板不在数据库层，而在存储物理拓扑里
mrp_recovery_parallelismpalallel_recovery_parallelism_recovery_parallelism=4STRIPE_COLUMNSTRIPE_COLUMNSELECT NAME, TYPE, STRIPE_COLUMN FROM V$ASM_DISKGROUP;_recovery_parallelism=8db file sequential readenq: RO - fast object reuseSTRIPE_COLUMNdb_recovery_file_destARCHIVE_LAG_TARGETSHOW PARAMETER ARCHIVE_LAG_TARGET0Timer300V$ASM_DISKGROUPV$ASM_ALIASdb_recovery_file_destALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;STRIPE_COLUMN ≥ 4ALTER SYSTEM SET "_recovery_parallelism" = 4 SCOPE=SPFILE;ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;_recovery_parallelismSELECT PROCESS, STATUS, THREAD#, SEQUENCE# FROM V$MANAGED_STANDBY WHERE PROCESS LIKE 'MRP%';MRP0MRP1MRP0db file sequential readlog file parallel writeRedo ApplySTRIPE_COLUMNEXTERNAL REDUNDANCY