v$managed_standby中无mrp0行说明恢复未启动，需先确保备库处于mount状态，再执行alter database recover managed standby database using current logfile disconnect。
备库v$managed_standby里找不到MRP0进程
MRP没启动，不是“卡住”，而是根本没起来。常见于备库刚启动后未手动启用实时应用，或上次cancel后没重开。
直接查：v$managed_standby中process列是否真有MRP0行。没有就说明恢复压根没开始，别查alert日志白费时间。
- 先确认备库处于
MOUNT状态（OPEN READ ONLY下ALTER DATABASE RECOVER会报错） - 执行：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT; - 再查
v$managed_standby，process=MRP0且status为WAIT_FOR_LOG或APPLYING_LOG才算真正跑起来
MRP0存在但sequence#长期不更新
进程在，但不动——这是最危险的状态：它不报错、不退出，只静默挂起。常见诱因是归档损坏、undo段异常、控制文件时间戳错乱，或遇到ORA-00600内部错误。
别只看status=APPLYING_LOG就以为正常。重点盯sequence#字段，两次查询间隔30秒，值不变就是卡死。
- 立刻查备库
alert.log和log.xml，搜ORA-00600、corruption、undo、kcbr_apply_change - 不要直接
START，先CANCEL再重开：ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;，再执行启用命令 - 若反复失败，检查
v$archive_gap是否有缺口；若有，优先解决归档传输问题，否则MRP永远停在缺口处
主库归档根本没发到备库
MRP再努力也无用——它等的日志压根不存在。80%的“MRP不动”问题根源在主库端传输中断。
先看主库：v$archive_dest_status中LOG_ARCHIVE_DEST_2的STATUS是否为VALID，ERROR字段是否为空。非空就按提示修，比如ORA-16057: DGID not set说明db_unique_name配置不一致。
- 查传输模式：
SHOW PARAMETER log_archive_dest_2，确认是LGWR ASYNC还是ARCH；ARCH模式下若v$archive_processes.state = 'WAIT_FOR_LOG'长时间不动，归档就卡在本地 -
LGWR ASYNC要查主库v$managed_standby中LNS进程的BLOCK#，连续两次不变说明网络阻塞或目标不可达 - 留意
DELAY=30这类配置，它会让归档人为延迟30分钟，别误判为故障
RMAN增量备份救急时MRP仍不启动
做完增量恢复后MRP还是起不来，大概率是化身（incarnation）不匹配或控制文件路径错乱。
尤其在19c+环境中，RECOVER STANDBY DATABASE FROM SERVICE或传统RMAN恢复后，备库可能落在旧化身分支上，导致MRP拒绝应用新归档。
- 在主库和备库分别执行：
LIST INCARNATION;，对比DB_KEY和INC_KEY - 若备库化身ID落后于主库最新
INC_KEY，需在备库MOUNT状态下执行：RESET DATABASE TO INCARNATION <inc_key>;</inc_key> - 恢复完控制文件后，务必检查
v$datafile中路径是否与备库实际存储位置一致；不一致会导致MRP找不到数据文件，直接静默退出
MOUNT状态下进行，OPEN状态下执行任何ALTER DATABASE RECOVER命令都会失败。MRP是否真在工作，只看v$managed_standby里MRP0是否存在、sequence#是否滚动、status是否持续变化——其余全是干扰项。
