mrp0状态为applying_log但sequence#长期不动，说明进程未死但卡在归档日志应用环节；需优先查备库alert.log中的ora-01111、ora-01193、corruption等错误，并检查主库新增pdb或数据文件后备库是否缺失对应路径或standby_file_management配置不当。
MRP0状态是APPLYING_LOG但sequence#长期不动
这说明进程没死，但卡在某个归档日志的应用环节。别只盯着v$archive_gap——它为空只代表归档收全了，不代表能应用。
优先查备库alert.log，搜这几个关键错误：
-
ORA-01111（UNNAMED文件） -
ORA-01193（数据文件不一致） corruption
特别注意主库新增PDB或数据文件后，备库standby_file_management设为MANUAL却没同步创建文件的情况：主库多出的+DATADG1路径，备库ASM里根本不存在，MRP0会静默挂起，不报错也不推进。
MRP0状态是WAIT_FOR_LOG但v$archive_gap为空
这不是归档没传过来，而是归档供应断了。主库可能已无法生成/提供连续归档——常见于主库联机日志损坏后，归档传输会静默中断。
检查主库是否真在持续归档：
- 执行
ALTER SYSTEM ARCHIVE LOG CURRENT，然后ls -l看log_archive_dest_1目录是否有新文件生成 - 查
v$archive_dest_status中STATUS是否为VALID，ERROR列是否非空；常见如ORA-09285（权限不足）或ORA-16038（日志重用） - 确认主库
ARCHIVE LOG LIST输出含Database log mode: Archive Mode
MRP0根本起不来，报ORA-01111或ORA-01274
这是典型的“UNNAMED文件”问题，本质是备库缺少对应的数据文件。
处理步骤必须严格按顺序：
- 先执行
ALTER SYSTEM SET standby_file_management='MANUAL' SCOPE=BOTH - 再用
ALTER DATABASE CREATE DATAFILE '/path/UNNAMED00019' AS '/real/path/test02.dbf'重建文件 - 最后恢复
ALTER SYSTEM SET standby_file_management='AUTO' SCOPE=BOTH
漏掉任意一步，或路径写错、ASM磁盘组不存在，都会导致MRP0反复失败。
转换为Snapshot Standby后MRP0起不来
快照备库不是“临时打开读写”的快捷方式，它依赖闪回机制和FRA空间。如果转换前没停掉MRP，或FRA空间不足，MRP0会因ORA-38705或ORA-16139卡住。
关键检查点：
-
SELECT NAME, SPACE_LIMIT, SPACE_USED FROM V$RECOVERY_FILE_DEST，确认SPACE_USED / SPACE_LIMIT -
SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY WHERE PROCESS = 'MRP0'，必须返回空或STATUS = 'IDLE'才可执行CONVERT TO SNAPSHOT STANDBY - 转换后必须显式执行
ALTER DATABASE OPEN，否则数据库仍处于MOUNTED状态，MRP0无法启动
MRP0挂起最隐蔽的根源，往往不在日志传输层，而在数据文件层面——尤其是新增对象后standby_file_management未生效、FRA空间耗尽、或UNNAMED文件残留。这些地方不手动验证，光看视图容易误判。
