实时同步延迟需分层定位传输层、应用层、资源层；确认ADG启用须满足database_role=PHYSICAL STANDBY、open_mode=READ ONLY WITH APPLY、recovery_mode=MANAGED REAL TIME APPLY；transport lag与apply lag呈因果链关系；真实延迟应通过DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER计算；gap需先判别类型再处理。
实时同步延迟不是“有没有”，而是“在哪卡住”——必须分层定位：传输层、应用层、资源层，漏掉一层就可能白查两小时。
怎么确认备库真启用了Active Data Guard
很多延迟问题其实压根没进ADG流程，备库还卡在只读挂起状态。先别急着查lag，直接连备库跑这句：
SELECT database_role, open_mode, recovery_mode FROM v$database, v$archive_dest_status WHERE dest_id = 2;
只有同时满足以下三点才算真正启用ADG：
-
database_role是PHYSICAL STANDBY -
open_mode是READ ONLY WITH APPLY -
recovery_mode是MANAGED REAL TIME APPLY（不是MANAGED STANDBY）
常见错误是只执行了 ALTER DATABASE OPEN READ ONLY，但忘了启动MRP进程，或者启动后被自动中断。查 V$MANAGED_STANDBY 看 PROCESS = 'MRP0' 且 STATUS = 'APPLYING_LOG'，否则日志根本没动。
transport lag 和 apply lag 哪个更关键
这两个值必须在主库查 V$DATAGUARD_STATS，备库查不到。它们不是并列关系，而是因果链：
-
transport lag > 0且apply lag = 0→ 日志还没传到备库，问题出在主库端或网络（TNS不通、归档路径不可写、LOG_ARCHIVE_DEST_2的ERROR字段有报错） -
transport lag = 0但apply lag > 0→ 日志已到备库但应用慢，重点看备库I/O、STANDBY_REDO_LOG组数/大小、MRP进程是否被阻塞（查V$SESSION_EVENT等待事件） - 两者都持续增大 → 很可能是归档堆积导致磁盘满，先查
V$RECOVERY_FILE_DEST的SPACE_USED / SPACE_LIMIT比值是否 ≥ 95%
注意：apply lag 显示 +00 00:00:00 不代表零延迟，只是Oracle当前估算无显著滞后；它背后依赖的是 STATISTICS_LEVEL = TYPICAL，否则该视图为空。
为什么DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER比current_scn更准
v$database.current_scn 在备库上长期不动，不代表异常——它只在日志应用完成时更新，而ADG是边收边应用的。真正反映“用户能查到什么”的，是当前已应用的SCN点。
所以必须用：
SELECT DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER FROM DUAL;
分别在主库和备库立刻执行（间隔控制在1秒内），差值除以每秒SCN增速（约2~4万/秒）才是真实延迟秒数。这个操作要快，否则主库SCN又涨了，结果失真。
容易踩的坑：
- 备库没给用户授予
FLASHBACK ANY TABLE权限，会报ORA-30014: operation only allowed in a flashback database - RAC环境只在一个节点执行，其他节点SCN不同步，得每个实例都查
- 误把
V$DATAGUARD_STATS.apply_lag当成铁律，它其实是基于统计模型估算的，网络抖动时偏差可达分钟级
查到gap之后，别急着scp归档
看到 V$ARCHIVE_GAP 有记录，第一反应不是手动拷日志，而是先确认gap类型：
-
GAP_STATUS = 'RESOLVABLE GAP'→ Oracle自己能拉，等2分钟再查，大概率自动补齐 -
GAP_STATUS = 'UNRESOLVABLE GAP'→ 主库那段归档已被清理，必须人工干预：从主库查V$ARCHIVED_LOG找对应NAME，scp过去，再在备库ALTER DATABASE REGISTER PHYSICAL LOGFILE '<path>' -
GAP_STATUS = 'LOCALLY UNRESOLVABLE GAP'→ 这段日志不在本主库，但在另一台主库（比如RAC多实例），得去别的节点找
最常被忽略的一点：gap未必是归档丢了，也可能是备库RFS进程因权限/磁盘满/监听故障没写进归档目录，此时查 V$MANAGED_STANDBY 会发现 PROCESS = 'RFS' 状态异常（NOT ACTIVE 或 CONNECTED 但无 SEQUENCE# 更新），而不是MRP卡住。
