备库MRP进程卡在重做应用且APPLIED长期为NO，主库执行DBMS_REDEFINITION引发重做风暴是常见原因；需先查v$archived_log中APPLIED='NO'且BLOCKS异常偏小的连续归档日志以验证。
备库MRP进程卡在重做应用，APPLIED状态长期为NO
主库执行 dbms_redefinition 时会产生大量细粒度、高频率的 dml（如逐行 insert/update/delete），这些操作被记录为海量小事务重做日志。备库 mrp 进程默认单线程应用这类日志，极易出现“积压—延迟—卡死”循环。现象是：v$archived_log 中大量 applied='no'，v$managed_standby 显示 mrp0 状态为 applying_log 但 sequence# 长期不推进。
确认是否因重定义触发重做风暴
不要直接假设是重定义导致——先验证。在备库执行：
SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME, BLOCKS, APPLIED FROM v$archived_log WHERE APPLIED = 'NO' AND FIRST_TIME > SYSDATE - 1/24 ORDER BY SEQUENCE#;
若发现连续多个归档日志的 BLOCKS 异常偏小（如 FIRST_TIME 时间戳密集（秒级间隔），且与主库执行 start_redef_table 或 sync_interim_table 的时间吻合，基本可锁定为重定义引发的重做流特征。
提升MRP并行度：从1到4（需谨慎）
Oracle 11g 支持通过 ALTER DATABASE RECOVER MANAGED STANDBY DATABASE PARALLEL 启用并行应用，但必须满足两个硬性前提：
-
COMPATIBLE参数 ≥11.2.0（11g R2 起支持，检查SELECT VALUE FROM V$PARAMETER WHERE NAME='compatible';） - 备库必须处于
MANAGED RECOVERY模式（非READ ONLY）
操作步骤：
1. 停止当前恢复：ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
2. 启用并行（例如设为4）：ALTER DATABASE RECOVER MANAGED STANDBY DATABASE PARALLEL 4 USING CURRENT LOGFILE DISCONNECT;
3. 验证生效：SELECT PROCESS, THREAD#, SEQUENCE#, STATUS FROM V$MANAGED_STANDBY WHERE PROCESS LIKE 'MRP%'; —— 应看到 MRP0 ~ MRP3 共4个进程
⚠️ 注意：并行度并非越高越好。若备库 I/O 或 CPU 已饱和，盲目调高反而加剧争用。建议从 PARALLEL 2 起步，观察 v$sysstat 中 physical reads 和 CPU used by this session 变化再调整。
同步完成后必须降回单线程
重定义操作结束、归档日志积压清空后，务必将 MRP 切回单线程模式。原因有二：
- 并行应用会显著增加备库 undo 表空间压力，尤其在重定义涉及大表时，
UNDO可能迅速膨胀甚至报ORA-01555 - 日常归档日志以大事务为主（如批量导入、ETL），单线程应用效率更高，并行反而引入调度开销
执行：ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;，再以默认方式重启：ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;
这个切换动作容易被忽略，但恰恰是避免后续备库隐性故障的关键点。
