ADG备库上AWR不采集任何数据，因只读模式下Oracle硬编码跳过MMON采样；需通过V$DATAGUARD_STATS、V$MANAGED_STANDBY、V$ARCHIVED_LOG等实时视图监控延迟与应用状态。
Active Data Guard备库上AWR根本不会采集
Active Data Guard物理备库默认禁用AWR快照，不是“采集不完整”，而是压根不生成——因为备库是只读状态，DBA_HIST_*系列表的写入被Oracle主动屏蔽。你看到的“No data exists”或空报告，是设计使然，不是配置错误。
- 主库的AWR数据（如
DBA_HIST_SQLSTAT、DBA_HIST_SYSTEM_EVENT）依赖后台进程MMON定期采样并写入WRH$表，而这些操作在只读备库上被跳过 -
V$ACTIVE_SESSION_HISTORY在ADG备库中也为空，因为ASH依赖会话活动写入，而备库无用户DML/DDL，仅MRP进程应用日志，不触发ASH采样 - 即使手动执行
DBMS_WORKLOAD_REPOSITORY.create_snapshot()，也会直接报错ORA-16000: database open for read-only access
想看备库性能？别指望AWR，改查实时视图
AWR在ADG备库上没用，但关键指标其实都在内存里，只是不在历史表里。你需要连上备库直接查实时动态性能视图：
-
V$DATAGUARD_STATS：看apply lag和transport lag，注意这两个值是心跳估算（默认60秒间隔），跨公网时可能滞后数分钟，不能当秒级延迟用 -
V$MANAGED_STANDBY：确认PROCESS='MRP0'的STATUS是否为APPLYING_LOG，SEQ#是否持续追平主库V$LOG_HISTORY最新序列 -
V$ARCHIVED_LOG：对比DEST_ID=2 AND ARCHIVED='YES'与APPLIED='YES'的SEQUENCE#差值，这才是真实应用延迟的序列级证据
STATISTICS_LEVEL设成TYPICAL也没用
有人试过把ADG备库的STATISTICS_LEVEL改成TYPICAL甚至ALL，结果还是没AWR数据——这不是参数没生效，而是Oracle硬编码逻辑：只要数据库OPEN模式为READ ONLY WITH APPLY，MMON就跳过所有AWR相关采样任务。
-
CONTROL_MANAGEMENT_PACK_ACCESS设成DIAGNOSTIC+TUNING也不起作用，许可证控制只影响主库 -
DBA_HIST_SNAPSHOT在备库里能看到记录，但SNAP_ID全是0，BEGIN_INTERVAL_TIME为空，说明快照元数据都没写进去 - 第三方监控工具（比如Zabbix Oracle插件）连备库后查
DBA_HIST_SYSMETRIC_SUMMARY返回空集，不是SQL写错，是表本身没数据
真要诊断备库I/O或应用慢？盯住底层指标
备库性能问题往往藏在I/O和MRP调度里，AWR看不到，但OS和Oracle底层视图能挖出来：
- 查
V$RECOVERY_PROGRESS里的ITEM='Media Recovery'行，看SO FAR和TOTAL比值是否长期卡住，结合V$SESSION_LONGOPS确认MRP是否在重放某个大事务 - 查
V$FILESTAT和V$IOSTAT_FILE，重点看PHYBLKRD和AVGIOTIM，如果AVGIOTIM > 10ms且PHYBLKRD/Sec突增，说明备库磁盘跟不上归档重放节奏 - 操作系统层用
iostat -x 1看%util和await，比任何AWR指标都早暴露I/O瓶颈
ADG备库的AWR是空的，这事没法“修复”，只能接受它本来就没数据。真正该花时间的地方，是把V$MANAGED_STANDBY和V$ARCHIVED_LOG的查询变成日常巡检脚本，而不是反复调参数试图唤醒一个根本没打算工作的模块。
