alter system set _recovery_parallelism 无效，因该隐含参数仅在实例启动时从spfile读取一次；需停库→修改spfile→重启才生效，且须配合applyparallel属性、i/o能力及parallel_max_servers等资源协同配置。

oracle dg 中的 parallel media recovery 并行度不能“按需设置”，它由隐含参数 _recovery_parallelism 控制，且仅在实例启动时读取一次；运行中 alter system 修改完全无效。

为什么 ALTER SYSTEM SET _RECOVERY_PARALLELISM = 8 没效果？

这个参数是 Oracle 内部隐藏参数，只在数据库启动阶段从 spfile 或 init.ora 加载一次。运行中执行 ALTER SYSTEM 不会触发重载，也不会影响正在运行的 MRP 进程。常见错误现象包括：

• 修改后查询 v$parameter 看到值变了，但恢复速度毫无变化
• AWR 中仍只看到 1 个 MRP0 进程，或并行 worker 数始终为 1
• 报 ORA-00600: [kcrf_update_ckpt] 等内部错误，实为并行恢复未真正启用

必须停库 → 修改 spfile → 启动实例，才能生效。

_RECOVERY_PARALLELISM 的合理取值范围

该参数只对 ARCHIVELOG 模式下的归档日志应用（即 RECOVER MANAGED STANDBY DATABASE）起作用，不控制实时应用（APPLY ON）或 SQL Apply 阶段。建议值为 CPU 核数的 1–2 倍，但：

GitHub Actions Retry Recovery Audit

审计 GitHub Actions 运行，检测失败后成功的重试恢复模式，量化 flaky 重运行的浪费。

下载

• ≤ 8 是较稳妥的上限；超过后因 latch 争用反而拖慢恢复
• 若物理备库 I/O 能力弱（如单盘 SAS 或 NFS），设高值只会加剧 I/O queue，无实际收益
• 需同步检查 parallel_max_servers 是否足够（例如设为 16 时，该值至少 ≥16）
• 确认系统级限制：Linux 的 nofile 必须 ≥ _RECOVERY_PARALLELISM × 2，否则启动并行 worker 会失败（报 “parallel recovery failed to get any processes”）

并行恢复没起来？先看这三件事

并行恢复是否真正启用，不取决于参数名是否看着“开了”，而取决于底层资源是否就绪、路径是否匹配、模式是否支持：

• 确认数据库处于 MOUNT 状态且已开启 ARCHIVELOG：用 SELECT log_mode FROM v$database; 验证
• 检查 Data Guard 配置中 ApplyParallel 属性是否为 AUTO 或显式数值（DGMGRL> EDIT DATABASE 'xxx' SET PROPERTY ApplyParallel=8;），该属性与 _RECOVERY_PARALLELISM 协同作用，但仅在 ADG 场景下生效
• 查 AWR 报告中 “Background Processes” 部分：若只有 MRP0，没有 PR00~PR07 类进程，则并行根本未启动——此时别调参数，先查 trace 目录下 mrp*.trc 中是否有 “failed to spawn parallel recovery slaves” 提示

真正卡点往往不在参数本身，而在 I/O 子系统能否撑住并发 redo 解析和块写入。一个 32 核机器设 _RECOVERY_PARALLELISM=16，若归档日志放在单块 SATA 盘上，结果只是把磁盘队列拉满，吞吐反降。优化方向永远是先解瓶颈，再谈并行。