最底层同步判断依据是主库current_scn与备库applied_scn的差值，建议控制在10000以内（高事务系统可放宽至50000）；差值过大说明应用滞后严重，applied_scn为空或为0则表明mrp进程未启动或卡住。

查主备库CURRENT_SCN和APPLIED_SCN是否接近

SCN差值是最底层、最不可绕过的同步判断依据。延迟为0不代表数据已应用，必须看备库实际已应用的SCN是否紧贴主库当前SCN。

在主库执行：

SELECT CURRENT_SCN FROM V$DATABASE;

在备库执行：

SELECT APPLIED_SCN FROM V$ARCHIVE_DEST WHERE TARGET = 'STANDBY';

两者差值建议控制在 10000 以内（高事务系统可放宽至 50000），超过说明应用滞后严重。

• 若备库APPLIED_SCN为空或为0，说明MRP进程未启动或卡住，不是延迟问题，是同步链路中断
• 主库CURRENT_SCN持续上涨但备库APPLIED_SCN长期不动，优先查V$MANAGED_STANDBY中MRP状态是否为APPLYING_LOG
• 不要只比一次——写个简单脚本每30秒查一次，观察差值是否收敛或震荡，避免误判瞬时抖动

用V$ARCHIVE_GAP确认有没有日志断档

V$ARCHIVE_GAP是备库上唯一能直接告诉你“缺哪几段归档”的视图，它不依赖时间估算，结果即事实。

在备库执行：

SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;

只要返回任意一行，就代表该THREAD#下从LOW_SEQUENCE#到HIGH_SEQUENCE#的日志完全缺失，必须人工补全。

• 常见误操作：看到没返回就认为“没问题”，其实可能是RFS进程根本没连上主库，日志都还没收进来
• 多线程环境（如RAC主库）必须检查每个THREAD#，漏掉一个线程，那个线程的DML就永远不同步
• 查到GAP后，不能直接去主库找对应序列号的归档——要先确认主库该THREAD#下SEQUENCE#是否真实存在且已归档，用V$ARCHIVED_LOG查，别信文件系统ls

对比主备库V$ARCHIVED_LOG中LAST SEQUENCE RECEIVED vs APPLIED

这个对比能暴露“日志收到了但没应用”的典型中间态，比如MRP挂起、standby redo log不足、或应用进程被阻塞。

Crypto Sniper Oracle

机构级量化市场预言机，提供订单簿失衡（OBI）、VWAP分析、自动化报告及Telegram预警。

下载

在备库执行（需保证RESETLOGS_CHANGE#一致）：

SELECT 
  (SELECT MAX(SEQUENCE#) FROM V$ARCHIVED_LOG WHERE DEST_ID=1) AS "Last Seq Received",
  (SELECT MAX(SEQUENCE#) FROM V$LOG_HISTORY) AS "Last Seq Applied"
FROM DUAL;

• 两个值相等且持续增长 → 同步健康
• “Received”远大于“Applied” → 日志堆积在归档目录但MRP没动，查V$MANAGED_STANDBY里MRP的STATUS和PROCESS列
• “Applied”不动但“Received”涨 → 备库可能缺standby redo log，或STANDBY_FILE_MANAGEMENT设为MANUAL导致新增数据文件阻塞应用

检查V$DATAGUARD_STATS里的apply lag是否可信

V$DATAGUARD_STATS里的apply lag字段只能在主库查，且是估算值，不是实时指标。它依赖主库对备库心跳探测，网络抖动或主库负载高时会失真。

在主库执行：

SELECT NAME, VALUE FROM V$DATAGUARD_STATS WHERE NAME IN ('apply lag', 'transport lag');

注意：VALUE是INTERVAL DAY TO SECOND类型，不能直接比较数字大小。

• 必须用EXTRACT(SECOND FROM apply_lag)换算成秒再判断，否则WHERE apply_lag > 60会报ORA-00932类型错误
• apply lag显示为+00 00:00:00.000000 ≠ 数据已可见——它只表示“按时间戳推算无延迟”，真实一致性仍取决于SCN是否追平
• 如果apply lag和transport lag都为NULL，大概率是主库STATISTICS_LEVEL被设为BASIC，需改回TYPICAL并重启统计收集

真正难的是交叉验证：SCN差值、GAP结果、日志序列号、MRP进程状态这四者必须逻辑自洽。任何一项异常，都不能靠其他项“看起来正常”就放行——生产环境里，同步断裂往往就藏在“看起来差不多”的缝隙里。