并行介质恢复（MRP）非CPU密集型，但并行度配置失当会引发shared pool/library cache latch争用，导致CPU空转；需结合redo速率、I/O能力及ADG模式综合调优，盲目提高并行度反而加剧性能问题。
并行介质恢复（MRP）进程本身不是CPU密集型操作，但并行度配置失当会直接引发CPU争用
Oracle Data Guard的介质恢复进程（MRP）默认是单线程的；一旦启用并行恢复（ALTER DATABASE RECOVER MANAGED STANDBY DATABASE PARALLEL 4），每个并行slave都会独立解析归档日志、应用redo、校验块一致性。这些操作本身不“计算密集”，但大量并发线程在共享内存结构（如library cache、shared pool）上频繁争抢latch，导致CPU时间大量消耗在自旋等待而非实际工作上。
常见现象包括：v$session_wait中出现大量latch: shared pool或latch: library cache等待；AWR报告里DB CPU占比高，但Top SQL中几乎看不到MRP相关SQL——说明CPU耗在底层争用，而非SQL执行。
- 并行度设为
PARALLEL N时，实际启动的slave数 =N，但每个slave还会额外派生辅助进程（如ARCn、RFS协同线程），总线程数可能达2N+2 - 若
sga_target未预留足够空间，shared pool碎片化加剧，latch争用指数级上升 - 12c中启用
INMEMORY或ADG（Active Data Guard）时，并行恢复与实时查询会竞争同一组buffer cache latch
检查并行恢复是否真在“并行”，还是卡在I/O或锁等待上
先确认CPU高是否真由MRP驱动：查v$managed_standby，看PROCESS列中MRP0和MRP1~MRPn的状态是否全为APPLYING_LOG；如果大量显示WAIT_FOR_LOG或IDLE，说明并行没跑起来，CPU高大概率是其他会话或后台进程（如MMON_SLAVE）导致，和MRP无关。
再查v$session中MRP相关会话的event和state：
SELECT sid, serial#, event, state, p1text, p1, p2text, p2 FROM v$session WHERE program LIKE '%MRP%';
若event是log file sequential read且state为WAITING，说明瓶颈在磁盘I/O（如归档路径慢、ASM磁盘组过载），此时调高并行度只会让I/O队列更长、CPU空转更多。
PARALLEL参数值不能只看CPU核数，要结合redo生成速率和I/O吞吐反推
盲目设PALALLEL 8在16核机器上未必合理。关键看单位时间redo量：
- 用
SELECT NAME, VALUE FROM V$DATAGUARD_STATS WHERE NAME = 'transport lag'确认传输延迟是否持续大于0——若传输已滞后，提高并行度无意义，先解决网络或主库LOG_ARCHIVE_DEST_n配置 - 查
v$archived_log最近1小时归档大小：SELECT SUM(BLOCKS*BLOCK_SIZE)/1024/1024/3600 MB_PER_SEC FROM v$archived_log WHERE FIRST_TIME > SYSDATE-1/24。若MB_PER_SEC ，PARALLEL 2足够；若>50，再考虑PARALLEL 4 - Linux下用
iostat -x 1观察standby端磁盘%util是否长期>90%，是则I/O已达极限，并行度再高只会增加CPU空转
12c特有陷阱：ADG开启时并行恢复与实时查询共用同一SGA区域
在Active Data Guard模式下，MRP和前台查询会同时访问buffer cache，而12c默认启用_db_block_hash_latches自动调整，但该参数在高并发恢复场景下可能过度收缩hash latch数量，导致严重争用。
临时缓解方法（需重启实例）：
ALTER SYSTEM SET "_db_block_hash_latches" = 2048 SCOPE=SPFILE;
更稳妥做法是关闭ADG实时查询（ALTER DATABASE OPEN READ ONLY而非READ WRITE），或改用STANDBY_MAX_DATA_DELAY = 0配合单线程MRP，把CPU节省下来给查询用——多数业务场景下，秒级延迟可接受，没必要为“零延迟”付出CPU翻倍代价。
真正难处理的是MRP和MMON_SLAVE（比如ORA-12850报错关联的Automatic Report Flush任务）同时活跃，两者都重度依赖shared pool，这种组合在12.1.0.2小版本中尤为常见，补丁12.1.0.2.190716之后才修复底层latch分配逻辑。别指望调参能根治，该升级就得升级。
