备库生成AWR报告需设STATISTICS_LEVEL=ALL并用主库快照ID；只读慢主因是服务名误配、I/O问题或日志应用拖累；ASH数据有2–10分钟延迟，应查V$ACTIVE_SESSION_HISTORY而非DBA_HIST_ACTIVE_SESS_HISTORY。
如何从备库生成有效的 AWR 报告
active data guard 备库默认不自动收集 awr 快照，直接运行 awrrpt.sql 会报错 ora-13502: cannot create awr snapshot on a standby database。这不是权限或脚本问题，而是 oracle 的硬限制——备库的 awr 快照由主库控制，但报告本身可以基于备库的实时性能数据生成。
关键在启用备库本地统计收集：必须设置 STATISTICS_LEVEL = ALL（不能是 TYPICAL），并确认 DBA_HIST_SNAPSHOT 在备库可查（它实际来自主库归档的 AWR 数据，通过 ADG 的 redo 应用同步过来）。
- 检查是否已启用：
SELECT NAME, VALUE FROM V$PARAMETER WHERE NAME = 'statistics_level'; - 若为 TYPICAL，需在备库执行：
ALTER SYSTEM SET STATISTICS_LEVEL = ALL SCOPE=BOTH;（重启非必需，但部分指标需新会话生效） - 生成报告时，用
@?/rdbms/admin/awrrpti.sql，起始/结束快照 ID 填主库上对应时段的 ID（可通过DBA_HIST_SNAPSHOT在备库查到，DBID和INSTANCE_NUMBER要匹配主库）
只读性能瓶颈最该盯的三个等待事件
ADG 备库的“只读慢”，90% 不出这三类等待：一是应用连接没走只读服务名，二是物理 I/O 毛病，三是日志应用拖累查询。别一上来就查 SQL，先看 V$SESSION_EVENT 或 AWR Top 5 Events 里是否高频出现：
-
read by other session：典型块争用，多见于频繁访问相同热块（如序列号表、状态标志位），且备库未开启DB_BLOCK_CHECKING = OFF（默认 ON，加重 CPU 和 IO） -
log file sync（出现在备库？）：说明备库正在承担部分写压力（比如误启用了 Active Data Guard 的 DML 功能，或有ENABLE PLUGGABLE DATABASE下的本地 UNDO 配置错误） -
gc cr block busy或gc current block 2-way：RAC 环境下跨实例块请求延迟高，但 ADG 备库本不该有 GC 等待——如果出现，说明应用连到了 RAC 主库的某个节点，而非 ADG 备库的服务名
为什么 DBA_HIST_ACTIVE_SESS_HISTORY 在备库查不到最近 5 分钟数据
ADG 备库的 ASH 数据不是实时采集的，它依赖主库的 ASH 写入归档日志，再经 redo apply 解析后落库。这个过程有延迟，通常 2–10 分钟不等，取决于归档传输速度、apply 延迟和 _ash_disk_filter_ratio 隐含参数（默认 0.5，即只保留一半采样）。
这意味着你执行 SELECT * FROM DBA_HIST_ACTIVE_SESS_HISTORY WHERE SAMPLE_TIME > SYSDATE - 1/288 很可能返回空——不是没数据，是还没刷进来。
- 查“当前”活跃会话，用
V$ACTIVE_SESSION_HISTORY（内存视图，实时但只保留 1 小时左右） - 查历史趋势，必须接受滞后性；若需准实时分析，得在应用层打点（比如在 SQL 前加
/*+ MONITOR */并查V$SQL_MONITOR） - 别试图调大
_ash_disk_filter_ratio：它只影响落盘比例，不解决延迟本质，还可能撑爆 SYSAUX 表空间
只读服务名配置不当导致的隐性性能损耗
很多 DBA 配了 SERVICE_NAME 却没设 CLB_GOAL = SHORT 和 LOAD_BALANCE = ON，结果连接全挤在一个实例上，CPU 和 buffer cache 压力集中，看起来像“只读慢”，其实是负载不均。
更隐蔽的是：如果主库用了 TAF（Transparent Application Failover），而备库服务名没关 TAF，客户端重连时可能反复尝试切回主库，造成连接抖动和超时累积。
- 检查服务配置：
srvctl config service -d <db_name>，确认Preferred instances指向备库实例 - 禁用备库服务的 TAF：
srvctl modify service -d <db_name> -s <service_name> -q off -j short -B NONE -e NONE - 验证连接路由：
SELECT INSTANCE_NAME, SERVICE_NAME FROM V$SESSION WHERE USERNAME IS NOT NULL;，确保SERVICE_NAME是你定义的只读服务名，不是主库的默认服务
ADG 的只读性能问题，很少卡在 Oracle 内核，多数出在服务路由、参数继承和监控视角错位——比如拿主库的 AWR 参数套备库，或者用主库的等待事件解释备库现象。细节对不上，结论就偏了。
