如何调整备库并行恢复_RECOVERY_PARALLELISM与并行度参数-Oracle-PHP中文网

\_recovery\_parallelism 仅实例启动时生效，运行中alter system无效；它只影响崩溃/介质恢复的redo应用并行度，需在spfile/init.ora中设置并重启，建议值为cpu核数1–2倍（≤8），且仅对archivelog模式下的归档日志应用有效。

为什么改了 `_recovery_parallelism` 没效果？

这个参数是 oracle 内部隐藏参数，仅在实例启动时读取一次，运行中修改 alter system set _recovery_parallelism = n 完全无效。它不控制 sql 应用阶段的并行，只影响崩溃恢复（crash recovery）或介质恢复（media recovery）中 redo 应用的并行 worker 数量。

常见错误现象：ORA-00600: internal error code, arguments: [kcrf_update_ckpt] 或恢复速度没变化，其实根本没生效。

必须在 init.ora 或 spfile 中设置，并重启备库实例
值建议设为 CPU 核数的 1–2 倍，但超过 8 后收益极小，还可能因 latch 争用拖慢恢复
仅对归档日志应用（ARCHIVELOG 模式 + RECOVER MANAGED STANDBY DATABASE）起作用，对实时应用（APPLY ON）无影响

`PARALLEL` 和 `MAX_PROCESSES` 怎么配合调？

备库 redo 应用的真正并行度，由 PARALLEL 子句（在 RECOVER MANAGED STANDBY DATABASE 中）和系统级 max_processes 共同约束。前者是“申请”，后者是“上限”。

典型场景：你写了 RECOVER MANAGED STANDBY DATABASE PARALLEL 4，但 max_processes 是默认 300，结果只起了 2 个 MRP 进程——因为其他后台进程（如 DBWR、LGWR、ARCn）已占满配额。

查当前使用：SELECT * FROM v$resource_limit WHERE resource_name = 'processes';
max_processes 至少要比 PARALLEL N + 常驻后台进程总数多出 20～30，否则 MRP 会静默降级为单线程
PARALLEL 值不是越大越好；实测 > 8 时，redo gap 大的场景下反而因协调开销导致吞吐下降

主库 `LOG_PARALLELISM` 会影响备库恢复吗？

不影响。这是个主库参数，控制的是 LGWR 写日志时的内部并行（比如 log writer worker），生成的 redo stream 对备库来说仍是线性字节流。备库看到的只是归档日志文件或传输过来的 redo，不继承主库写日志的并发方式。

容易踩的坑：有人以为调高主库 LOG_PARALLELISM 能加速备库应用，结果发现毫无改善，还误判网络或磁盘瓶颈。

备库恢复瓶颈通常在 I/O（归档日志读取）、CPU（redo 解析与应用）、或内存（db_recovery_file_dest_size 不足导致归档失败）
验证是否真卡在恢复：查 v$managed_standby 中 PROCESS 为 MRP0 的 STATUS 和 SEQ# 是否长期停滞
别碰 LOG_PARALLELISM —— 它对 Data Guard 架构无传导效应

真实有效的调优顺序是什么？

先保稳定，再提速度。很多 DBA 直接调 _RECOVERY_PARALLELISM，却忘了最基础的 I/O 和内存配置。

确认备库 db_recovery_file_dest 所在磁盘组有足够空闲空间且 I/O 延迟 iostat -x 1 看 %util 和 await）
检查 standby_file_management 是否为 AUTO，避免因新增数据文件阻塞 MRP
启用 RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT 替代传统归档应用，减少日志切换间隙
最后才动 _RECOVERY_PARALLELISM 和 PARALLEL，每次只调一个，观察 v$recovery_progress 的 ITEM 为 Active Apply Rate 的数值变化