MRP进程“停了”还是“卡死了”需通过连续查询v$managed_standby中SEQUENCE#变化、检查v$process与v$px_session是否异常、排查ALERT.LOG中ORA-01111等错误及MRP trace中ORA-600[2619]定位归档损坏，并确认UNNAMED文件残留和fast_start_parallel_rollback参数影响。
MRP进程“停了”还是“卡死了”，得先分清
光看 v$managed_standby 里 status 是 wait_for_log 或 applying_log 不够——它可能根本没在动。要确认是不是真“频繁停止”，而不是静默卡住：
- 连续执行三次
SELECT PROCESS, STATUS, SEQUENCE#, LAST_TIME FROM v$managed_standby WHERE PROCESS = 'MRP0';，间隔30秒，观察SEQUENCE#是否递增、LAST_TIME是否更新 - 查
v$process里是否有多个P00x进程（比如P000~P007），但v$px_session为空：这是并行恢复已启动却死锁的典型信号 - 别只扫
alert.log，重点翻最近1小时内的错误行，盯住重复出现的ORA-01111、ORA-01157、ORA-01274、ORA-600[2619]
UNNAMED文件残留是MRP起不来的头号原因
UNNAMED 不是临时状态，是控制文件里写死的错误登记项。MRP每次启动都会撞上它，然后退出——哪怕你清空FRA、重启实例、甚至重传密码文件，它都还在。
- 在备库
MOUNT状态下运行：SELECT file#, name FROM v$datafile WHERE name LIKE '%UNNAMED%';，只要返回结果非空（例如/u01/app/oracle/product/12.1.0/dbhome_1/dbs/UNNAMED00042），MRP就不可能稳定运行 - 修复前必须确认：
STANDBY_FILE_MANAGEMENT是AUTO，且DB_FILE_NAME_CONVERT已正确配对，否则CREATE DATAFILE ... AS会建错路径 - 如果主库早已删掉对应表空间，且你确认不需要该数据，可用
ALTER DATABASE DATAFILE 42 OFFLINE DROP;（42 是查出的file#），再ALTER DATABASE OPEN;；但不要在OPEN状态下直接删控制文件条目
ORA-600[2619] 多半是归档日志损坏，不是bug
这个错误不会留在 alert.log 里，只写进 MRP 自己的 trace 文件。它本质是 MRP 读到一个 next_change# 异常的归档块，通常因为备库磁盘满导致归档写入中断——哪怕 ls -l 看大小一致，内容也可能被截断。
- 先从
alert.log开头找Errors in file行，定位 trace 路径，如/u01/diag/rdbms/stb/STB/trace/STB_mrp0_12345.trc - 用
grep -i "ORA-600\|next_change" STB_mrp0_*.trc | tail -5快速抓最后几行，确认报错指向哪个具体归档序列号 - 在主备两端分别执行
md5sum对比该归档文件，不一致就说明备库上的文件异常，必须重传——mv 备份旧文件，再从主库拷贝一份过来
fast_start_parallel_rollback=LOW 在备库反而坏事
Oracle 12c 默认值是 LOW，但在备库应用大事务时，它会让 SMON 拉起一堆 PX 进程争抢 undo 资源，最终锁死整个恢复流程。这不是配置没生效，而是配置本身在备库场景下有害。
- 查当前值：
SHOW PARAMETER fast_start_parallel_rollback; - 若为
LOW或MEDIUM，建议临时设为IMMEDIATE：ALTER SYSTEM SET fast_start_parallel_rollback=IMMEDIATE SCOPE=BOTH; - 改完后重启 MRP：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;→ 再DISCONNECT FROM SESSION
真正麻烦的从来不是单个错误代码，而是 UNNAMED 条目+归档损坏+并行参数三者叠加——它们各自都能单独让 MRP 停摆，合起来会让排查变成循环重启。动手前务必先查 v$datafile 和 trace，别一上来就 CANCEL 再 DISCONNECT。
