oracle 11g物理备库的mrp0进程天然是单线程的，不支持并行日志应用；alter database recover...parallel语句无效或静默降级，v$managed_standby中始终仅见一个mrp0进程。
oracle 11g 物理备库无法通过开启 parallel 实现多线程日志应用——mrp0 进程天然是单线程的，alter database recover ... parallel 语句在 11g 中无效或静默降级。
Oracle 11g 的 MRP0 不支持并行恢复
你在 11g 物理备库上执行 RECOVER MANAGED STANDBY DATABASE PARALLEL 4，实际不会启动多个 MRP 进程。MRP0 是一个严格串行、按 SCN 顺序重放变更的专用进程，它不调用 P00x 并行服务进程，也不受 PARALLEL_MAX_SERVERS、_RECOVERY_PARALLELISM 等参数控制。
常见误操作现象：
- SQL 执行成功但
v$managed_standby里始终只看到一个MRP0进程 - 设置
PARALLEL 8后 alert.log 出现 “parallel recovery failed to get any processes”，回退为单线程 - 监控显示 CPU 利用率低，误以为“资源没用上”，实则是 I/O 等待（如
log file parallel write、db file sequential read）卡住
哪些 PARALLEL 相关参数在 11g 备库上真正起作用？
能生效的只有两类场景，且都和“实时日志应用”无关：
-
_RECOVERY_PARALLELISM：仅在实例启动时读取，影响崩溃恢复（crash recovery）或介质恢复（media recovery）阶段的 redo 应用并行度；运行中ALTER SYSTEM修改完全无效 -
PARALLEL子句 +max_processes配合：仅对显式执行RECOVER DATABASE（非 managed standby 模式）有效；而 ADG 场景下必须走RECOVER MANAGED STANDBY DATABASE，该路径不走此逻辑
注意：LOG_PARALLELISM 是主库 LGWR 内部参数，对备库日志应用无任何影响。
备库追不上主库的真实瓶颈在哪？
别再调并行参数了，直接查这三个地方：
-
standby redo log 组数不足：若备库
STANDBY REDO LOG组数 ≤ 主库ONLINE REDO LOG组数，RFS 进程会因日志被覆盖而阻塞；建议至少比主库多 2 组，且每组大小 ≥ 主库最大 online log - 归档路径与数据文件共盘：MRP0 同时做随机读（datafile）、顺序写（standby log）、顺序读（archivelog），混在同一磁盘组会导致 I/O 争用；必须物理隔离存储，比如归档单独挂 SSD 或专用 ASM 磁盘组
- ARCHIVE_LAG_TARGET = 0：主库每秒触发归档检查，引发高频小 IO，加剧争用；除非 RPO 要求秒级且存储确认无瓶颈，否则设为 300（5 分钟）更稳
那 11g 真的完全不能并行吗？
严格来说：物理备库不能；逻辑备库（Logical Standby）可以，但它需要构建 LogMiner 字典、转换为 DML 执行，适用场景受限（不支持 BFILE、ADT、物化视图日志等），且 11g 逻辑备库维护成本高、补丁风险大。
所以如果你正用着 11g 物理备库，又看到延迟持续扩大，优先检查 v$archive_gap 是否有缺口、v$managed_standby 中 MRP0 的 status 是否真是 APPLYING_LOG，再看磁盘响应时间是否 > 10ms——这些地方出问题的概率，远高于“并行没开起来”。
