adg备库从oracle 12.2起支持生成awr报告，但默认不生效；需启用rmf框架、解锁sys$umf用户、建立双向dblink、配置拓扑并创建远程快照，才能使报告真实反映备库只读负载。
adg备库能直接生成awr报告吗？12.2+ 是，但默认不生效
oracle 12.2起支持在adg备库采集awr数据，但不是开箱即用。备库默认仍沿用主库的awr快照（即dba_hist_snapshot来自主库归档），查到的报告反映的是主库负载，而非备库真实只读压力。
要让报告真正体现备库查询负载，必须启用Remote Management Framework（RMF）并配置远程快照——核心是把备库设为“源库”（source），主库设为“目标库”（destination），由主库主动拉取备库的实时性能数据。
- 仅设置
STATISTICS_LEVEL = ALL不够，那只是让备库能采集本地ASH，但AWR报告仍无法独立生成 - 必须解锁
SYS$UMF用户，并在主备间双向建DBLINK（如DBL_STDBY_TO_PRIM和DBL_PRIM_TO_STDBY） -
DBMS_UMF.configure_node和DBMS_UMF.register_node必须在主库执行，且node_name必须与备库DB_UNIQUE_NAME严格一致
生成报告前必验三项：服务名、快照、延迟
即使RMF配置完成，报告也可能“看起来对、实际错”。常见失效点集中在连接路径和数据时效性上。
- 确认应用连的是ADG专用只读服务名（如
mydb_ro），而不是主库服务名或通用服务名；tnsping mydb_ro通 ≠ 实际路由到备库，需查V$SESSION.SERVICE_NAME - 检查远程快照是否真被创建：
SELECT SNAP_ID, DBID, INSTANCE_NUMBER FROM DBA_HIST_SNAPSHOT WHERE DBID = (SELECT DBID FROM V$DATABASE@DBL_STDBY_TO_PRIM) AND INSTANCE_NUMBER = 1（注意用DBLINK查主库视图） - 验证应用延迟：
SELECT VALUE FROM V$DATAGUARD_STATS@DBL_STDBY_TO_PRIM WHERE NAME = 'apply lag'，若>5秒，说明备库数据滞后，此时生成的报告反映的是“过期负载”
只读慢？先盯这三个等待事件，别查SQL
ADG备库的AWR Top 5 Timed Events里，90%的只读性能问题集中在这三个事件，它们比SQL本身更早暴露架构或配置缺陷。
-
read by other session：热块争用，典型于序列号表、状态标志位等高频小表访问；备库未关DB_BLOCK_CHECKING会加剧此等待 -
log file sync出现在备库ASH中？说明有DML误写入——检查是否启用了ENABLE PLUGGABLE DATABASE且本地UNDO未禁用，或应用连错了实例 -
gc cr block busy或gc current block 2-way：RAC环境下出现即表明连接没走备库服务名，而是打到了主库RAC某节点，GC等待本不该在物理备库出现
为什么DBA_HIST_ACTIVE_SESS_HISTORY查不到最近5分钟数据？
这不是Bug，是ADG机制决定的延迟。备库的ASH数据来自主库归档日志中的采样记录，经redo apply解析后才落库，整个链路存在2–10分钟固有延迟。
所以你执行SELECT * FROM DBA_HIST_ACTIVE_SESS_HISTORY WHERE SAMPLE_TIME > SYSDATE - 1/288（5分钟）大概率为空。此时应改查V$ACTIVE_SESSION_HISTORY——它是内存视图，实时反映当前正在发生的会话活动，虽无历史持久化，但对定位“此刻卡在哪”最有效。
真正容易被忽略的是：_ash_disk_filter_ratio隐含参数（默认0.5）会丢弃一半采样，若需更高精度，需在备库调整该值并重启实例，但会显著增加I/O和存储开销。
