mrp进程未启动导致备库无法应用日志，需确认备库处于mounted或read only with apply状态、recovery_mode为managed real time apply、standby_file_management非manual且无unnamed文件、主库归档目的地启用且有效，再执行alter database recover managed standby database using current logfile disconnect。
MRP进程没启动，备库根本不会应用日志
MRP（Managed Recovery Process）不运行，备库就只是个“静态归档接收器”——日志传过来了，但没人去解析、重做。哪怕V$ARCHIVED_LOG里全是APPLIED = 'NO'，V$MANAGED_STANDBY里也查不到MRP0或MRP进程，这就是典型症状。
别急着查网络或归档路径，先确认状态：
-
SELECT PROCESS, STATUS, SEQUENCE# FROM V$MANAGED_STANDBY WHERE PROCESS IN ('MRP0', 'MRP');—— 如果没返回任何行，说明MRP根本没启动 -
SELECT OPEN_MODE, DATABASE_ROLE FROM V$DATABASE;—— 必须是MOUNTED或READ ONLY WITH APPLY；如果是READ ONLY，MRP无法启动 -
SELECT RECOVERY_MODE FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID = 2;—— 应为MANAGED REAL TIME APPLY，不是IDLE或空
启动MRP前必须满足的三个硬性条件
直接执行ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;失败，大概率是卡在这几处：
- 备库必须处于
MOUNT状态（物理备库）或READ ONLY WITH APPLY（Active Data Guard）。用ALTER DATABASE OPEN READ ONLY;之后再启MRP，会报ORA-16136: standby database is in read-only mode -
STANDBY_FILE_MANAGEMENT不能是MANUAL且存在UNNAMED数据文件。否则MRP一读到缺失文件就退出，报ORA-01111或ORA-01274 - 主库
LOG_ARCHIVE_DEST_STATE_2必须是ENABLE，且V$ARCHIVE_DEST_STATUS中对应DEST_ID=2的STATUS为VALID，ERROR列为空
启动MRP的标准命令与常见报错应对
确认前置条件满足后，执行：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;
这条命令本质是唤醒MRP0并让它开始拉取当前在线日志（Real Time Apply），不是只处理已归档日志。如果失败，重点看alert.log里紧跟的错误：
- 报
ORA-10458：控制文件SCN和数据文件头不一致 → 先跑RECOVER MANAGED STANDBY DATABASE（不带USING CURRENT LOGFILE），等它追平再加USING CURRENT LOGFILE - 报
ORA-16016或ORA-00308：归档日志有缺口 → 查V$ARCHIVE_GAP，手动补日志并REGISTER PHYSICAL LOGFILE - 报
ORA-01111/ORA-01274：数据文件缺失 → 临时设STANDBY_FILE_MANAGEMENT = MANUAL，用ALTER DATABASE CREATE DATAFILE '/path/UNNAMEDxxx' AS '/real/path.dbf'重建，再切回AUTO
MRP启动后仍不推进？盯住两个关键视图
命令返回Database altered不代表MRP真在干活。必须交叉验证：
-
SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK# FROM V$MANAGED_STANDBY WHERE PROCESS = 'MRP0';——STATUS必须是APPLYING_LOG，且SEQUENCE#随时间增长 -
SELECT MAX(SEQUENCE#), APPLIED FROM V$ARCHIVED_LOG WHERE FIRST_TIME > SYSDATE - 1 GROUP BY APPLIED;—— 确保最近1小时内的归档，APPLIED = 'YES'的MAX(SEQUENCE#)持续上升
如果SEQUENCE#卡死不动，或APPLIED长期为'NO'，说明MRP虽在运行，但被某个隐性问题阻塞：比如undo表空间无法自动扩展、FAL服务超时未补日志、或底层存储I/O延迟突增——这些不会直接报错，但会让MRP“假活”。
