查v$archived_log中最近归档的applied字段，若为'yes'表示已应用完成，并需结合completion_time与first_time时间差判断是否秒级延迟以确认实时恢复状态。
查 v$archived_log 看最近归档是否已应用
物理备库处于 read only 模式时，日志应用（mrp）进程默认是停止的；但如果你启用了 read only with apply（即实时查询+实时恢复），就必须确认 mrp 是否真在运行。最直接的办法是查 v$archived_log 中最近几条记录的 applied 字段：
-
APPLIED = 'YES'表示该归档日志已被应用（注意：不是“正在应用”，而是已完成） - 重点看
COMPLETION_TIME和FIRST_TIME的时间差 —— 若差值在秒级（比如 - 若大量日志
APPLIED = 'NO'，且STANDBY_DEST = 'YES'，说明 MRP 进程没启动或已异常中断
检查 MRP 进程是否存在且状态正常
物理备库要实现实时应用，必须有 MRP0（Managed Recovery Process）在后台运行。仅靠 SELECT OPEN_MODE FROM V$DATABASE 返回 READ ONLY 并不能说明它在应用日志。
- 执行
SELECT PID, SPID, PROGRAM, STATUS FROM V$PROCESS WHERE PROGRAM LIKE '%MRP%';—— 若无结果，MRP 未启动 - 若有结果但
STATUS = 'STOPPED'或'WAITING'（长期卡在WAIT_FOR_LOG），需进一步查V$MANAGED_STANDBY -
V$MANAGED_STANDBY中关注PROCESS = 'MRP0'的STATUS和SEQUENCE#：若SEQUENCE#长期不更新，大概率卡住
对比主库和备库的当前日志序列号
这是判断延迟最直观的方式，尤其适合快速排查是否“掉队”。注意不是比归档序号，而是比 LOG_ARCHIVE_DEST_2（或其他 standby dest）上主库刚生成、备库应接收的日志序列。
- 主库查：
SELECT MAX(SEQUENCE#) FROM V$LOG_HISTORY;（或更准的SELECT SEQUENCE# FROM V$LOG WHERE STATUS='CURRENT'） - 备库查：
SELECT MAX(SEQUENCE#) FROM V$ARCHIVED_LOG WHERE APPLIED='YES'; - 两者的差值 ≤ 1 且稳定，可认为实时；差值 ≥ 3 并持续扩大，说明应用滞后或中断
- 注意：如果主库切换频繁（如每分钟切几次），而备库
APPLIED序列长时间不动，MRP 很可能已 hang 住
警惕 READ ONLY 下误以为“自动应用”的常见错觉
很多人看到数据库是 READ ONLY 就默认日志在同步，其实 Oracle 默认行为是：进入 READ ONLY 后 MRP 自动中止。所谓“实时应用”必须显式启动，且依赖正确配置。
- 启动命令是：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;（不是OPEN READ ONLY本身触发的） - 如果之前用
ALTER DATABASE OPEN READ ONLY启动，MRP 已停，必须先SHUTDOWN IMMEDIATE，再用STARTUP MOUNT，再执行 recover 命令，最后ALTER DATABASE OPEN READ ONLY - 若使用 Data Guard Broker，
SHOW DATABASE输出中的Apply State必须是APPLYING_LOG，而非READY或ERROR
真正容易被忽略的是：MRP 进程一旦因网络抖动、归档缺失或权限问题失败，不会报错到 alert.log 明显位置，而是静默停留在 WAIT_FOR_LOG —— 所以不能只看数据库是否 open，得盯住 V$MANAGED_STANDBY 里 MRP0 的实时状态。
