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 倍，但：
- ≤ 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 盘上，结果只是把磁盘队列拉满，吞吐反降。优化方向永远是先解瓶颈，再谈并行。
