mrp0默认只在单个实例运行，因它是单实例进程；需在每个节点手动执行recover managed standby database parallel命令并确保共享归档路径，才能实现双节点并行日志应用。
MRP0 进程默认只在单个实例启动，这是 Oracle RAC 物理备库的默认行为，不是故障；要实现双节点并行日志应用，必须显式启用 RECOVER MANAGED STANDBY DATABASE 并指定 PARALLEL。
为什么 MRP0 只在一个节点运行？
Oracle 19c RAC 备库中，MRP0（Managed Recovery Process）是单实例进程，不跨节点自动拉起。即使两个节点都处于 READ ONLY WITH APPLY 状态，也仅有一个节点的 MRP0 默认启动——通常是第一个被 srvctl start database 启动的实例，或第一个完成 ALTER DATABASE OPEN READ ONLY WITH APPLY 的节点。
常见误判点：看到 V$MANAGED_STANDBY 中有 RFS 和 ARCH 在所有节点 RUNNING，就认为同步正常，但 MRP0 可能只在节点 1 存在且 STATUS = 'APPLYING_LOG'，节点 2 的 MRP0 行为空或为 NOT APPLYING。
- 查证方式：
SELECT INST_ID, PROCESS, STATUS, THREAD#, SEQUENCE# FROM GV$MANAGED_STANDBY WHERE PROCESS = 'MRP0'; - 若仅一个
INST_ID返回结果，说明另一节点未参与日志应用 -
V$DATAGUARD_STATS.TRANSPORT_LAG和APPLY_LAG持续增长，往往就源于此
如何让两个节点都运行 MRP0？
不能依赖 Broker 自动分发，必须手动在每个节点上独立启动并行恢复。注意：这不是“开启多实例 MRP”，而是让每个节点各自承担一部分日志应用任务，前提是归档日志已通过 RFS 分发到本地归档目录（或共享 ASM 归档位置）。
- 确保两节点均以
READ ONLY WITH APPLY打开：ALTER DATABASE OPEN READ ONLY WITH APPLY; - 在节点 1 执行：
RECOVER MANAGED STANDBY DATABASE PARALLEL 4 USING CURRENT LOGFILE DISCONNECT; - 在节点 2 **同样执行**该语句（不是
START或RESUME，必须是完整命令） - 验证：
GV$MANAGED_STANDBY中两个INST_ID都应有PROCESS = 'MRP0'且STATUS = 'APPLYING_LOG'
⚠️ 关键限制：并行恢复要求所有节点访问相同的归档日志路径（推荐使用 ASM 共享磁盘组），若归档路径为本地文件系统，节点 2 无法读取节点 1 生成的归档，MRP0 将立即报错 ORA-00308 或卡在 WAIT_FOR_LOG。
PARALLEL 参数值设多少才合理？
数值不是越大越好，需结合 I/O 能力、日志生成速率和 CPU 核心数综合判断。RAC 备库场景下，盲目设高反而引发争用。
- 建议起始值：
PARALLEL 2或PARALLEL 4（每节点） - 若备库使用高速 NVMe 存储 + 16 核以上 CPU，可尝试
PARALLEL 8，但务必监控V$RECOVERY_PROGRESS中的ITEM = 'Active Apply Rate'是否线性提升 - 避免跨节点设置不同
PARALLEL值——这不会带来收益，反而增加latch free等等待 - 检查是否真正在并行：
SELECT * FROM GV$SESSION_LONGOPS WHERE OPNAME LIKE 'Media Recovery%';应在两个节点都看到活跃条目
Broker 会接管并行恢复吗？
不会。Data Guard Broker（DGMGRL）在 RAC 备库中仅管理数据库级生命周期（ENABLE/DISABLE DATABASE），不控制 MRP0 的启动位置或并行度。即使你用 EDIT DATABASE ... SET STATE = 'APPLY-ON'，Broker 也只会触发第一个可用实例上的 MRP0，其余节点仍静默。
这意味着：日常运维中，只要发生过主备切换或节点重启，就必须人工确认两节点的 MRP0 状态，并在必要时补发 RECOVER 命令——这个动作无法固化进 CRS 资源定义，也无法通过 Broker 自动化。
最容易被忽略的一点：节点 2 的 MRP0 即使成功启动，若其所在实例的 _log_apply_max_lag 隐含参数被意外修改（比如从默认 0 改为 300），也会导致它拒绝应用超过 5 分钟滞后的日志，表现为“启动了但不干活”。排查时别只盯 STATUS，还得看 V$DATAGUARD_STATS.APPLY_LAG 是否真实收敛。
