调高 PARALLEL_MAX_SERVERS 对 Oracle 11g 物理备库日志应用速度基本无效，因其由单线程 MRP0 进程串行执行，不受并行参数控制；真正影响速率的是 standby redo log 配置、磁盘 I/O 性能及归档传输效率。
直接结论：调高 parallel_max_servers 对 oracle 11g 物理备库的日志应用速度基本无效，甚至可能加重延迟。
物理备库（Physical Standby）的日志应用由 MRP0 进程（Managed Recovery Process）单线程串行执行，它不走并行执行框架，也不受 PARALLEL_MAX_SERVERS、PARALLEL_DEGREE_POLICY 等并行参数控制。你看到的“应用慢”，根源不在并行资源不足，而在 I/O、归档传输瓶颈或 standby redo log 配置不当。
为什么改 PARALLEL_MAX_SERVERS 没用
MRP0 是一个专用恢复进程，其行为是严格按 SCN 顺序重放归档日志或 standby redo log 中的变更块。它不会把一个归档切分成多个 chunk 并发 apply，也不启动 P00x 类型的并行服务器进程。即使你把 PARALLEL_MAX_SERVERS 设为 512，MRP0 仍只用一个 OS 线程干活。
常见误判场景：
- 看到主库有大量并行 DML，就以为备库也该并行 apply —— 实际上，DML 的并行性在归档日志里已固化为单一线性变更流
- 监控到备库 CPU 利用率低，就认为“还有并行资源没用上”—— 其实是磁盘读写或日志解析卡在 I/O 等待上
- 错误地把逻辑备库（Logical Standby）的并行机制套用到物理备库
真正影响物理备库应用速度的三个关键点
排查和优化必须聚焦在这三处，而非并行参数：
- standby redo log 组数不足：当主库归档切换频繁（如每分钟多组），而备库 standby redo log 组数 ≤ 主库 online redo log 组数时，MRP0 来不及消费完一组，下一组就覆盖了，导致 RFS 进程阻塞、传输暂停。建议备库 standby redo log 至少比主库多 2 组，且每组大小 ≥ 主库最大 online redo log
-
磁盘 I/O 能力饱和：MRP0 需要随机读取 datafile 块 + 顺序写入 standby redo log + 顺序读取归档/standby log。若存储响应时间 > 10ms 或 await 长期 > 50ms，应用必然拖慢。优先检查
v$sysstat中physical reads和redo writes的等待事件（如log file parallel write、db file sequential read） -
网络与归档传输配置：确认
LOG_ARCHIVE_DEST_2使用了ASYNC（非SYNC），且未启用DELAY；检查NET_TIMEOUT是否过小导致频繁重连；归档目录是否位于高延迟 NFS 或满空间文件系统
什么情况下才该动 PARALLEL_MAX_SERVERS
这个参数只对以下两类场景有意义：
-
逻辑备库（Logical Standby）：SQL Apply 使用协调进程（LSP0）+ 多个应用进程（P00x），此时提高
PARALLEL_MAX_SERVERS可增加并发 apply 线程数（需配合MAX_SERVERS参数） - 备库上跑查询（Active Data Guard）：仅当你在只读打开的备库上执行大表扫描、分区索引重建等耗时 SQL 时，这些 SQL 才会真正用到并行服务器，此时调高该参数才有意义
但注意：Oracle 11g 的 Active Data Guard 是企业版特性，且默认不启用并行 —— 你得显式加 /*+ PARALLEL(t,4) */ Hint 或设置会话级 ALTER SESSION ENABLE PARALLEL DML，否则照样单线程跑。
最常被忽略的一点：哪怕你把 PARALLEL_MAX_SERVERS 调得再高，只要 PROCESSES 参数更小，所有并行服务器都会被硬性截断。检查 show parameter processes，确保它 ≥ PARALLEL_MAX_SERVERS + 预估连接数（否则会报 ORA-00020）。
