V$DATAGUARD_STATS 是主库专属视图，备库上查询为空或报 ORA-00942 错误，因其依赖主库主动探测机制，备库不维护该统计上下文。
为什么在备库查不到 V$DATAGUARD_STATS 的数据
因为 V$DATAGUARD_STATS 是主库专属视图，备库上查它必然为空或报 ORA-00942: table or view does not exist —— 这不是权限问题，也不是你漏授角色，是 Oracle 内部设计决定的。该视图依赖主库对备库状态的主动探测和聚合逻辑，备库自身不维护这套统计上下文。
常见错误现象：
- DBA 在备库反复执行
SELECT * FROM V$DATAGUARD_STATS，返回空结果，误以为监控失效或 DG 链路异常 - 用脚本自动采集该视图，在备库节点部署后始终无数据，却未检查执行位置
实操建议：
- 必须登录主库实例（
sqlplus / as sysdba）再查 - 确认当前用户有
SELECT_CATALOG_ROLE或显式授予SELECT ON SYS.V_$DATAGUARD_STATS - 检查
SHOW PARAMETER STATISTICS_LEVEL，值必须为TYPICAL（默认即满足），否则字段全为空
查 V$DATAGUARD_STATS 时字段名大小写和空格敏感
NAME 字段的值是严格区分大小写且含空格的字符串，比如 'apply lag'（注意中间有空格），不是 'apply_lag'、'Apply Lag' 或 'applylag'。写错就查不到对应行。
正确写法示例：
SELECT * FROM V$DATAGUARD_STATS WHERE NAME = 'apply lag';
常见错误现象：
- WHERE 条件写成
WHERE NAME LIKE '%lag%'，可能匹配到多个无关行（如'transport lag'和'apply lag'混在一起） - 复制网上示例时漏掉空格，变成
'applag'，查询返回零行
transport lag 和 apply lag 字段不能直接数值比较
这两个字段类型是 INTERVAL DAY TO SECOND，值形如 +00 00:05:23，不是整数秒。在 SQL 或 PL/SQL 中直接写 apply_lag > 60 会触发类型不匹配错误。
正确提取秒数的做法：
SELECT EXTRACT(DAY FROM apply_lag) * 86400 +
EXTRACT(HOUR FROM apply_lag) * 3600 +
EXTRACT(MINUTE FROM apply_lag) * 60 +
EXTRACT(SECOND FROM apply_lag) AS apply_lag_seconds
FROM V$DATAGUARD_STATS
WHERE NAME = 'apply lag';
容易踩的坑：
- Shell 脚本里用
awk '{print $3}'截取+00 00:05:23的分钟位，但字段格式不稳定（可能变+01 02:03:04），导致解析失败 - EM 13c 告警规则里填了“阈值 30”，但没选“单位=秒”，实际比对的是 INTERVAL 类型，永远不触发
apply lag 显示 0 并不等于查询实时可见
即使 apply lag 返回 +00 00:00:00，应用在备库执行 SELECT 仍可能看不到主库刚提交的数据。这是因为该字段只是基于日志头时间戳与系统时钟差的估算值，不反映真实 SCN 同步进度。
真正可信的延迟判断方式是比对主备 SCN：
- 主库执行：
SELECT DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER FROM DUAL; - 立刻在备库执行同样语句
- 两 SCN 差值 ÷ 备库
V$DATAGUARD_STATS中'estimated startup time'的倒数（约每秒 SCN 增速），得出真实延迟秒数
注意：如果备库 DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER 返回值长期不变，说明 MRP0 进程已卡住，要立刻查 V$MANAGED_STANDBY 的 PROCESS 和 STATUS 列。
