备库未启用Real-time Apply则查询看不到最新提交；需确认MRP0状态为APPLYING_LOG且BLOCK#持续增长，并通过AS OF SCN实现强一致性查询。
备库没开 real-time apply，查询就必然看不到最新提交
Oracle 11g 物理备库默认不启用实时应用（Real-time Apply），即使归档日志已传到备库，MRP0 进程也只在日志“完整写满”后才开始应用。主库刚 COMMIT 的事务，其重做记录可能还在当前联机日志或未归档的归档日志末尾，备库根本还没读到，更谈不上应用和 SCN 推进。
必须确认并启用 Real-time Apply：
- 检查是否已启用：
SELECT RECOVERY_MODE FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID = 2;—— 返回MANAGED REAL TIME APPLY才算生效；若为MANAGED STANDBY，说明只是普通归档应用，无实时性 - 启用方式（需备库处于
READ ONLY WITH APPLY状态）：ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT; - 启用后立即验证：
SELECT PROCESS, STATUS, SEQUENCE#, BLOCK# FROM V$MANAGED_STANDBY WHERE PROCESS = 'MRP0';——STATUS应为APPLYING_LOG，且BLOCK#持续增长 - 注意：该命令会终止原有 MRP 进程并重启，如果之前是
WAIT_FOR_GAP或卡在某序列号，需先解决归档缺失问题再执行
为什么 V$DATAGUARD_STATS 的 apply lag 不可靠
V$DATAGUARD_STATS 里的 apply lag 是估算值，依赖后台统计周期和 SCN 增速模型，不能反映真实查询可见性。它可能显示 “0 seconds”，但你 SELECT 仍查不到刚提交的数据 —— 因为备库实际已应用的 SCN 还没追上主库提交时的 SCN。
真正可信的是直接比对 SCN：
- 主库执行：
SELECT DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER FROM DUAL; - **立刻**在备库执行同样语句（两次查询间隔控制在 1 秒内）
- 差值 ÷ 当前 SCN 增速（查
V$DATAGUARD_STATS中estimated startup time对应的每秒 SCN 增量，通常 1~5 万/秒）≈ 实际延迟秒数 - 备库查不到数据，大概率是这个差值 > 0，且
MRP0的SEQUENCE#滞后于主库当前归档序列
常见误操作：只开 read only，没启 MRP 或没配 real-time
很多人以为执行了 ALTER DATABASE OPEN READ ONLY; 就能查到新数据，其实这只是让备库“可读”，但没启动恢复进程，SCN 完全不动。更隐蔽的坑是：开了 READ ONLY WITH APPLY，但没运行 USING CURRENT LOGFILE，MRP0 仍在等归档写满 —— 表现就是 V$MANAGED_STANDBY 里 MRP0 状态是 WAIT_FOR_LOG 或 APPLYING_LOG 但 BLOCK# 长期不变。
- 确认状态组合：
SELECT DATABASE_ROLE, OPEN_MODE FROM V$DATABASE;必须返回PHYSICAL STANDBY和READ ONLY WITH APPLY - 确认 MRP0 在跑：
SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY WHERE PROCESS = 'MRP0';—— 缺失该行或STATUS为NOT APPLYING，说明根本没启恢复 - RAC 环境下，
USING CURRENT LOGFILE只在当前实例生效，其他实例需单独执行，否则部分节点查不到新数据
应用端想“强制看到某次提交”，别等自动同步
业务逻辑中，主库刚插入一笔订单并拿到返回，紧接着就要在备库查这条记录 —— 这种场景不能靠等待 Real-time Apply“自然跟上”，因为网络抖动、I/O 峰值都可能导致短暂卡顿。正确做法是用 AS OF SCN 主动锚定：
- 主库提交后，立刻获取 SCN：
SELECT DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER FROM DUAL; - 把该 SCN 值传给备库查询：
SELECT * FROM orders AS OF SCN 123456789 WHERE order_id = 1001; - 注意：备库必须已启用 Flashback（
DB_RECOVERY_FILE_DEST配置且空间充足），且用户有FLASHBACK ANY TABLE权限 - 该语句不依赖当前 MRP 进度，只要该 SCN 对应的块还保留在备库的归档或闪回区中，就能查出
Real-time Apply 不是开关一按就“实时”，它依赖归档传输稳定、MRP 进程存活、备库 I/O 能力足够 —— 任何一环卡住，SCN 就停摆。查不到数据时，第一反应不该是调参数，而是看 V$MANAGED_STANDBY 里 MRP0 是否真在动、SEQUENCE# 是否在涨、BLOCK# 是否在跳。
