备库mrp进程可能静默停止，需检查v$managed_standby中process=mrp0且status为wait_for_log或applying_log；若无mrp0则需手动启用实时应用，若有但sequence#不变则查alert.log；同时确认主库归档传输状态、备库归档缺口及实时应用是否真正开启。
备库mrp进程是否真在运行
mrp（managed recovery process）不报错也不退出，但可能早已静默 halt。常见诱因包括归档缺失、坏块、控制文件时间戳异常或应用时遇到 undo 段问题。光看 v$managed_standby 里状态是 applying_log 不够——得确认 process 列确实是 mrp0，且 status 是 wait_for_log 或 applying_log，而不是 not applying 或空值。
检查命令：select process, status, sequence#, client_process from v$managed_standby where process in ('MRP0', 'RFS');
- 若无
MRP0行，说明恢复没真正启动，需手动启用：alter database recover managed standby database using current logfile disconnect; - 若
MRP0存在但sequence#长期不变，优先查alert.log和log.xml，重点搜ORA-00600、ORA-01110、corruption、undo关键词 - 别直接重启 MRP：先
cancel再重开，避免残留锁或挂起状态：alter database recover managed standby database cancel;
归档日志有没有真正传到备库
备库收不到归档，八成是主库压根没发出去。先看主库 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 还是 ARCH，以及是否带 ASYNC、AFFIRM=NO、DELAY 等修饰。
-
ARCH模式下，主库必须完成本地归档后才触发传输，若ARCH进程卡住（查v$archive_processes中state = 'WAIT_FOR_LOG'却长时间不动），归档就发不出去 -
LGWR ASYNC更实时，但网络抖动易导致LNS进程 BLOCK# 停滞——可查主库：select process, status, sequence#, block# from v$managed_standby where process = 'LNS';，连续两次查询block#不变即可疑 -
DELAY=30这种配置会人为延迟 30 分钟，检查v$archive_dest的delay_mins值，别误判为故障
备库有没有归档缺口（GAP）
v$archive_gap 是第一道快速筛查工具，但它只反映“接收缺口”，不反映“应用缺口”。查出来有 gap，说明 RFS 进程没收到某段连续归档；查出来为空，不代表数据已应用——可能日志全收到了，但 MRP 卡在某条上没往下走。
执行：select thread#, low_sequence#, high_sequence# from v$archive_gap;
- 有结果：去主库用
list archivelog from sequence <low_seq> until sequence <high_seq> thread <thread>;</thread></high_seq></low_seq>找出对应归档，scp到备库相同路径（路径必须和log_archive_dest_2中定义的完全一致） - 传完别急着
recover automatic，先手动注册：alter database register physical logfile '<full_path_to_arch>';</full_path_to_arch>，这能绕过 RFS 对文件时间戳/大小的严格校验 - 注册后再执行
recover automatic standby database;，观察是否继续推进
实时应用（Active Data Guard）是否真开启
物理备库默认只做介质恢复，不提供只读服务。要支持实时查询，必须开启实时应用（Real-Time Apply），否则即使归档全收全应用，v$archived_log.applied 显示 YES，也只是“归档级同步”，不是“秒级同步”。
检查命令：select recovery_mode from v$archive_dest_status where dest_id = 2;
- 返回
MANAGED REAL TIME APPLY才算真正开启；若是MANAGED STANDBY，说明只靠归档文件应用，延迟取决于日志切换频率 - 开启方式：
alter database recover managed standby database using current logfile disconnect;—— 注意必须带using current logfile，否则只是归档应用模式 - 开启后，
v$managed_standby中应出现MRP0和RFS，且RFS的client_process应为LGWR（而非ARCH），这是实时应用的关键标志
最常被忽略的是：主库归档路径权限、备库归档目录磁盘满、db_file_name_convert 配置错误导致数据文件无法创建——这些不会直接报在 MRP 日志里，但会让应用在后台无声失败。
