timer等待占比超10%或每小时time_waited_ms增长超60000ms，表明dg进程异常阻塞；需结合v$session、v$event_histogram、transport/apply lag差值、scn比对及mrp0状态综合诊断。
查 Timer 等待占比是否异常升高
Timer 等待本身是 Data Guard 进程（ARCn、MRP、LNSn）的正常休眠行为，但若在 AWR 报告中占比超过 10% 或每小时 time_waited_ms 增长超 60000（即 60 秒），就说明进程频繁被阻塞后重试，不是“健康心跳”而是“病态喘息”。
直接运行：
SELECT event, total_waits, time_waited_ms,
ROUND(time_waited_ms*100/SUM(time_waited_ms) OVER(), 2) pct
FROM v$system_event
WHERE event = 'Timer';
- 如果
pct > 10，跳转查关联进程：用v$session和v$process找出哪些 DG 进程卡在 Timer 上 - 若同时出现
resmgr:cpu quantum或db file parallel write高等待，说明 Timer 升高是 CPU 或 I/O 资源不足的副作用，不是根源 - 别只盯平均值——
v$event_histogram查wait_time_milli分布，若 32ms 及以上档位占总量 20%+，基本可断定网络或存储已抖动
比对 transport lag 和 apply lag 的差值
V$DATAGUARD_STATS 里两个关键字段：transport lag 表示日志还没传到备库，apply lag 表示日志已到但没应用完。两者差值大，问题在主库端传输；差值小但 apply lag 持续涨，问题在备库端应用。
执行：
SELECT name, value FROM v$dataguard_stats
WHERE name IN ('transport lag', 'apply lag');
- 若
transport lag > apply lag + 30（秒），立刻查主库v$archive_dest_status的error列和status列，重点看LOG_ARCHIVE_DEST_2 - 若
apply lag单边上涨且V$MANAGED_STANDBY中PROCESS = 'MRP0'的STATUS是APPLYING_LOG，但SEQ#长期不更新，说明 MRP 卡在 I/O 或 SQL 层——此时查备库log file parallel write和db file sequential read平均等待是否超阈值 -
STANDBY_MAX_DATA_DELAY=0不等于实时，它只影响延迟报告值，不加速实际同步；设了还延迟，说明底层链路已瓶颈
用 SCN 差值算真实延迟，绕过 V$DATAGUARD_STATS 估算误差
V$DATAGUARD_STATS.apply lag 是 Oracle 根据 SCN 增速反推的估算值，网络抖动、备库负载波动时偏差可达数分钟。真实延迟必须靠主备两端 DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER 直接比对。
操作步骤：
- 主库立即执行：
SELECT DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER FROM DUAL;记下结果scn_primary - 同一会话（或极短时间内）在备库执行同样语句，得
scn_standby - 查备库 SCN 增速：
SELECT VALUE FROM V$DATAGUARD_STATS WHERE NAME = 'estimated startup time';——这个值其实是“每秒 SCN 增量倒数”，比如返回2.5，代表每秒约生成40000SCN - 真实延迟 ≈
(scn_primary - scn_standby) / (1000000 / VALUE)（单位：秒）
注意：DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER 在备库需 FLASHBACK ANY TABLE 权限；若备库 SCN 完全不动，V$MANAGED_STANDBY 里 MRP0 的 STATUS 很可能已是 WAIT_FOR_GAP 或 CONNECTED，不是 APPLYING_LOG。
确认 Active Data Guard 是否真启用，而非仅 OPEN READ ONLY
只执行 ALTER DATABASE OPEN READ ONLY 不等于启用了 Active Data Guard。必须同时满足两个条件：备库 open_mode 是 READ ONLY WITH APPLY，且 V$MANAGED_STANDBY 中存在状态为 APPLYING_LOG 的 MRP0 进程。
验证命令：
SELECT database_role, open_mode FROM v$database; SELECT PROCESS, STATUS, SEQUENCE#, THREAD# FROM v$managed_standby WHERE PROCESS = 'MRP0';
- 若
open_mode是READ ONLY（缺WITH APPLY），说明 MRP 没启动，所有查询都读的是“挂起快照”，根本不会同步 SCN - 若
MRP0.STATUS是WAIT_FOR_LOG或NOT ACTIVE，检查DB_RECOVERY_FILE_DEST是否空间满、归档目录权限是否可写、LOG_ARCHIVE_DEST_2是否配置了VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) - RAC 环境下，
MRP0只在一个实例运行，别在其他节点查——容易误判为“没进程”
SCN 同步不是线性推进的，尤其在 RAC 主库下，SCN 传播要跨实例协调；MRP 进程本身不直接推进 SCN，它只是驱动日志应用，而 SCN 推进依赖 LGWR 写盘 + LMS 传播 + 备库 redo 应用三者闭环。任何一个环节卡住，延迟就停在那儿不动，光调参数没用。
