应将fast_start_parallel_rollback设为FALSE。因MRP0停滞于大事务解析应用环节，禁用并行恢复可避免资源争抢与SMON死锁，实测提速2–5倍，且动态生效、无需重启，能快速清理僵局状态。
备库应用停滞在大事务上，不是因为日志没传过来，而是mrp0进程卡在“解析并应用”环节——此时调高log_parallelism或网络带宽毫无意义，真正该动的是事务级并行恢复控制参数。
怎么确认是大事务导致MRP0停滞
先别急着改参数，得验证是不是真卡在事务回滚/应用上：
- 查
v$managed_standby中PROCESS = 'MRP0'的STATUS是否长期为APPLYING_LOG，同时SEQ#长时间不递增（比如超5分钟无变化） - 查
v$transaction和v$session关联，看是否有USED_UBLK极大（>100万）且START_TIME很早的事务残留 - 查
v$fast_start_servers，如果出现多个RECOVERING状态进程但CPU占用不高、或大量IDLE进程挂在那里，说明并行恢复已失效甚至拖慢整体进度
fast_start_parallel_rollback设成FALSE最稳
Oracle 12c 的fast_start_parallel_rollback默认LOW（2 × CPU_COUNT），但对大事务反而容易引发资源争抢、锁等待、甚至SMON死锁。实测中，禁用并行恢复常比强行并行快2–5倍。
-
ALTER SYSTEM SET fast_start_parallel_rollback = FALSE SCOPE=BOTH;—— 动态生效，无需重启 - 执行后观察
v$fast_start_servers应快速清空，MRP0会退回到串行模式，不再拉起PX进程 - 注意：该参数只影响“实例崩溃后自动恢复”和“备库应用时的事务回滚”，不影响正常DML；设为
FALSE后，SMON会用单线程+更大_cleanup_rollback_entries（默认400）批量清理undo块，更可控
备库端避免触发并行恢复的隐藏条件
即使主库没出事，备库自己也可能“主动启动”并行恢复——比如你手动ALTER DATABASE RECOVER MANAGED STANDBY DATABASE中断后重试，或MRP异常终止再启，都可能让SMON误判需并行介入。
- 每次执行recover命令前，先查
v$fast_start_transactions，若STATE = 'PENDING'且UNDOBLOCKSDONE远小于UNDOBLOCKSTOTAL，说明已有残留事务，先等它自然结束或设FALSE再操作 - 不要在备库执行
ALTER SYSTEM CHECKPOINT或ALTER SYSTEM SWITCH LOGFILE——这些操作会强制触发instance recovery逻辑，意外激活并行恢复 - 若发现
v$process里有大量P00x进程但v$px_session为空，基本可断定是并行恢复残留，直接设FALSE+ 等待几分钟，Oracle会自动清理
真正难处理的不是参数本身，而是“并行恢复已启动但未完成”的中间态：它既不报错也不推进，v$fast_start_servers里进程状态卡在IDLE或RECOVERING，而MRP0完全不动。这种时候，FALSE不是权宜之计，而是唯一能打破僵局的操作。
