mrp频繁停止的根因是unnamed文件残留、归档校验失败或并行恢复卡死；需通过v$managed_standby连续查询sequence#变化、alert.log错误、v$datafile查unnamed、mrp trace定位ora-600[2619]及禁用fast_start_parallel_rollback等综合排查。
mrp进程频繁停止，不是配置没生效，而是它在反复遭遇可恢复但未被清除的故障点——最常见的是unnamed文件残留、归档校验失败、或并行恢复卡死。直接重启recover managed standby database只会让问题循环发生。
查MRP是否真在“频繁停止”，而不是静默卡住
光看v$managed_standby里STATUS是APPLYING_LOG或WAIT_FOR_LOG不够。要确认它是不是在“频繁”出问题：
- 执行
SELECT PROCESS, STATUS, SEQUENCE#, FIRST_TIME, LAST_TIME FROM v$managed_standby WHERE PROCESS = 'MRP0';，连续查3次（间隔30秒），看SEQUENCE#是否跳变、LAST_TIME是否停滞 - 检查
ALERT.LOG里最近1小时内是否有重复出现的ORA-01111、ORA-01157、ORA-01274或ORA-600[2619] - 查
v$process中是否存在多个P00x进程但v$px_session为空——这是并行恢复已启动却卡死的典型痕迹
UNNAMED文件残留是最常被忽略的根因
UNNAMED不是临时状态，是控制文件里写死的错误登记项，MRP每次启动都会重新撞上它。
- 在备库
MOUNT状态下运行：SELECT file#, name FROM v$datafile WHERE name LIKE '%UNNAMED%';，只要返回结果不为空，MRP就不可能稳定运行 - 这个条目不会随主库删表空间而自动消失；也不会因你清空FRA或重启实例而清除
- 修复前必须确认：
STANDBY_FILE_MANAGEMENT是AUTO且DB_FILE_NAME_CONVERT已配对，否则CREATE DATAFILE ... AS会建错路径
归档日志损坏或不完整会触发ORA-600[2619]
MRP读到半截归档就会报ORA-600[2619]并退出，但错误不会留在ALERT.LOG里——它只写进MRP自己的trace文件。
- 定位trace路径：先查
ALERT.LOG开头的Errors in file行，找到类似/u01/diag/rdbms/stb/STB/trace/STB_mrp0_12345.trc的路径 - 用
grep -i "ORA-600\|next_change" STB_mrp0_*.trc | tail -5快速定位最后几行，确认是否指向某个具体归档序列号 - 比对主备该归档的
md5sum，不一致就说明备库上的文件写入异常——哪怕ls -l大小一样，也得重传
fast_start_parallel_rollback=LOW反而让MRP更不稳定
Oracle 12c默认fast_start_parallel_rollback=LOW，但在备库应用大事务时，它会让SMON拉起多个PX进程争抢undo资源，最终锁死。
- 查当前值：
SHOW PARAMETER fast_start_parallel_rollback; - 动态禁用：
ALTER SYSTEM SET fast_start_parallel_rollback = FALSE SCOPE=BOTH;，无需重启 - 执行后观察
v$fast_start_servers应快速清空，v$transaction中USED_UBLK极大但START_TIME很早的事务会逐步被单线程清理掉 - 注意：这个参数只影响崩溃恢复和备库事务应用，不影响日常DML
真正难处理的不是单个错误，而是多个故障点叠加：比如FRA先满 → 归档写坏 → MRP报ORA-600[2619]退出 → 手动清理又没清干净UNNAMED → 再启MRP立刻再撞上。每一步都要验证，不能跳过。
