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