awr报告中top 5 timed events是首要分析项，反映数据库最耗时的5类等待事件；需结合业务场景判断是否异常，如db file sequential read在oltp常见但在dw占比超40%则需排查索引或分区剪枝问题。
怎么看awr报告里的top 5 timed events
这是awr报告里最该先看的地方，它直接告诉你数据库当前最耗时的5类等待事件。不是所有“高时间”都代表有问题——比如 db file sequential read 在oltp系统里占前两位很常见，但若出现在数据仓库场景且占比超40%，就得查sql是否走了错误索引或没走分区剪枝。
常见干扰项：latch: shared pool 或 library cache lock 往往指向硬解析过多，别急着调内存，先检查应用有没有绑定变量；enq: TX - row lock contention 则要结合ASH定位具体阻塞链，而不是只看等待总时长。
- 用
awr_report_text脚本生成文本版报告，避免HTML渲染掩盖原始数值精度 - 对比两个时段（如业务高峰 vs 低谷）的Top 5，差异大于2倍才值得深挖
- 注意“Time(s)”列是累计值，不是平均单次耗时——
log file sync时间短但次数多，可能拖慢整体TPS
SQL ordered by Elapsed Time 为什么不能直接信
这个列表按总执行耗时排序，但容易误导：一条跑10分钟的报表SQL，一天只跑1次，对系统压力远不如每秒执行5次、每次200ms的短SQL。真正该盯的是“每秒逻辑读”和“每秒执行次数”双高的SQL。
实操时先过滤掉 module 为 SQL*Plus 或 TOAD 的条目（人工操作），再按 Executions 列倒序扫——如果某SQL执行次数是其他SQL的10倍以上，即使单次耗时排不进前20，也要优先分析。
- 用
DBA_HIST_SQLSTAT补充查历史执行计划变化：plan_hash_value突变常伴随性能抖动 -
Elapsed Time per Exec (s)> 1s 且Executions> 1000，基本可判定为坏SQL - 注意
Parse Calls和Executions比值：接近1说明大量硬解析，绑定变量没生效
Buffer Gets和Physical Reads差10倍意味着什么
这两个指标差得越多，越说明物理IO压力大。Buffer Gets 是逻辑读（含内存命中），Physical Reads 是真去磁盘读块。比值低于10通常合理，但若低于5，尤其在SGA配置充足时，大概率是执行计划用了全表扫描却没走索引，或者索引选择性极差被优化器弃用。
别只看总量——用 DBA_HIST_SEG_STAT 查具体对象的 physical_reads，如果某张小表（
- 检查对应SQL的执行计划：
access_predicates和filter_predicates是否有隐式类型转换 - 运行
DBMS_STATS.LOCK_TABLE_STATS锁定关键表统计信息，避免自动收集导致计划突变 - 留意
direct path read等待：说明大数据量排序/哈希连接绕过了buffer cache，此时加大pga_aggregate_target可能比调SGA更有效
AWR快照间隔设成1小时真合适吗
默认1小时太粗糙。交易系统出现瞬时尖峰（比如秒杀开始后30秒CPU飙到95%），1小时粒度的AWR会把这30秒的负载摊平到整个区间，根本看不出异常。建议OLTP系统设为15–30分钟，批处理窗口内可临时缩到5分钟。
但别无脑调密——快照太密会撑大SYSAUX表空间，且 DBA_HIST_SNAPSHOT 记录本身也消耗资源。实测发现快照间隔
- 用
DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS调整，别手动删快照——否则DBA_HIST_*视图关联会断 - 高峰期前用
DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT手动打一个快照，确保关键窗口被捕获 - 定期清理：保留最近7天快照足够诊断多数问题，老快照用
DBMS_WORKLOAD_REPOSITORY.DROP_SNAPSHOT_RANGE清理
实际分析中，最常被忽略的是AWR和ASH的交叉验证——AWR告诉你“哪里慢”，ASH才能说清“谁在慢的时候干了什么”。比如Top 5里 cursor: pin S wait on X 高企，单看AWR只会想到shared pool，但ASH能直接定位到是某个存储过程反复执行 EXECUTE IMMEDIATE 导致游标争用。
