AWR报告中真正反映系统负载的指标是Avg Active Sessions（AAS）、DB CPU、Physical Reads/Writes Per Sec和Logons/Executions Per Sec；需结合采样一致性、业务场景及底层资源综合归因，而非孤立对比数值。
awr 报告本身不直接提供“系统负载”的单一指标，但它是 oracle 数据库层面负载基线分析最可靠的数据来源——关键在于理解哪些快照指标真正反映负载强度，以及如何排除干扰项。
怎么看 AWR 里真实的负载指标？
很多人一上来就盯着 DB Time 或 Logical Reads 看，但这两个值受业务量、SQL 效率、并发数共同影响，不能直接等同于“负载高”。真正有基线意义的是：
-
DB CPU：操作系统级 CPU 消耗（来自v$sysmetric的 1 分钟粒度聚合），排除 I/O 等等待后，反映纯计算压力； -
Physical Reads Per Sec和Physical Writes Per Sec：比总量更稳定，能识别持续 IO 压力，避免被单次大导入扭曲； -
Logons Per Sec和Executions Per Sec：结合看可区分是连接风暴（如连接池未复用）还是真实 SQL 执行压力； -
Avg Active Sessions (AAS)：AWR 报告顶部的这个值，是单位时间活跃会话均值，接近 1 表示单核满载，>CPU 核数即存在排队——这是最贴近“负载”直觉的指标。
为什么直接对比两个 AWR 报告容易误判？
基线不是简单挑两个时间段拉报告比数字。常见陷阱包括：
- 快照间隔不一致：
awr_snapshot_interval默认 60 分钟，但若某次手工采集间隔为 15 分钟，AAS值会被严重低估； - 采样窗口覆盖了异常事件：比如对比工作日 9–10 点和周末凌晨 2 点，但后者恰逢 RMAN 备份，
Physical Reads飙升不代表业务负载高； - 忽略了数据库内部状态：同一 AAS 下，大量
enq: TX - row lock contention和全是db file sequential read，对系统的实际影响完全不同； - 没过滤后台进程：
DB CPU包含ora_mmon_、ora_cjq0_等维护进程，高负载时段它们活动增多，会抬高数值但不反映用户压力。
怎么用 AWR 做有效基线？三步实操建议
不需要写脚本也能快速建立可用基线：
- 用
awrrpt.sql生成连续 7 天同一时段（如每天 14:00–15:00）的 AWR 报告，导出为文本后提取每份的Avg Active Sessions、DB CPU、Physical Reads Per Sec三列； - 把这 7 个值粘贴进 Excel，算标准差：若
AAS标准差 > 均值的 25%，说明该时段业务波动大，不适合作为静态基线，应改用滚动窗口（如最近 5 个工作日均值）； - 在出现性能问题时，运行当前 1 小时的 AWR 报告，重点比对这三个指标是否突破基线 +2σ（两倍标准差），而不是只看绝对值；若
AAS超标但DB CPU正常，大概率是 IO 或锁问题，不用急着加 CPU。
别忘了 AWR 的盲区
AWR 是数据库视角，它看不到：
- 主机层 CPU steal time（虚拟机环境）、内存 balloon、网络丢包——这些会导致
AAS升高但DB CPU不涨； - 存储阵列响应时间突增，可能让
db file scattered read平均等待达 100ms，但 AWR 只统计次数和总时间，不记录 P95/P99； - SQL 执行计划突变带来的逻辑读爆炸，可能使
Logical Reads Per Sec翻倍，但AAS几乎不变——这时得结合dba_hist_sqlstat查具体 SQL。
基线分析真正的复杂点，从来不在怎么取数，而在于判断哪个指标的偏离，对应哪一层的真实瓶颈。AWR 给你数据，但不替你做归因。
