aas超过cpu核数可断定为数据库内部资源争用或高负载导致响应延迟，因其将db time归一化为“等效并发会话数”，直接反映单位时间内实际活跃的虚拟用户量；而db time是绝对时间总和，未考虑cpu并行能力，单独使用易误判负载程度。
aas 超过 cpu 核数，基本可以断定是数据库内部资源争用或高负载导致响应延迟，不是网络或应用层问题
为什么看 Average Active Sessions（AAS）而不是 DB Time？
AAS = DB Time / Elapsed Time，它把绝对时间归一化成“等效并发会话数”，直接反映数据库在单位时间内实际忙了多少个“虚拟用户”。DB Time 单独看容易误导：比如 60 分钟内 DB Time 是 300 分钟，听起来很高，但如果系统有 16 个逻辑 CPU，AAS = 5，其实只是中等负载；反过来，若 AAS = 25 而 CPU 只有 8 核，说明大量会话在排队——这就是响应变慢的根源。
常见误判点：
- 只盯着
DB Time上升就认为“CPU 不够”，忽略了等待事件构成（比如大量enq: TX或latch: shared pool可能和 CPU 无关） - 用 AAS 和 OS load 直接等同——OS load 包含不可中断睡眠（如 D 状态），而 AAS 只统计前台会话的活跃时间
- 跨 RAC 实例直接加总 AAS 值——每个实例的 AAS 是独立计算的，不能简单相加
从 AWR 报告里快速定位 AAS 异常时段
打开 HTML 格式的 AWR 报告，直接搜索 “Average Active Sessions” —— 它通常出现在 “Instance Efficiency Percentages” 上方的 Summary 区域，带图表。注意两个关键值：
-
Begin Snap和End Snap对应的 AAS 值（非平均值，是该区间整体均值） - 图表中曲线是否持续高于 CPU 核数（可通过
cat /proc/cpuinfo | grep processor | wc -l或v$osstat查） - 如果 AAS 在某个子区间突然冲高（比如某 5 分钟达 12，其余时间
别依赖报告首页的“Top 5 Timed Events”就下结论——当 AAS 高时，这些事件往往是结果而非原因。例如 db file sequential read 排第一，未必是磁盘慢，可能是 SQL 逻辑读太多、buffer cache 命中率低（看 “Buffer Pool Statistics” 部分的 Buffer Nowait % 和 Redo Nowait %）。
AAS 高但 CPU 使用率低？重点查这几类等待
这是 Oracle 11g 最典型的“假空闲”现象：OS 显示 %idle 很高，但用户觉得卡。根本原因是会话没在 CPU 上跑，而是在等资源。重点关注：
-
cursor: pin S on X：共享池争用，尤其在硬解析频繁或 shared_pool_size 不足时（看 AWR 中 “Shared Pool Memory Statistics” 的 shrink 次数） -
enq: TX - row lock contention：行锁冲突，结合 “Segments by Row Lock Waits” 确认热点表 -
latch: cache buffers chains：热块争用，通常伴随高逻辑读 SQL，检查 “SQL ordered by Gets” -
direct path read：11gR2 后自动触发全表扫描绕过 buffer cache，若大量出现且平均等待 > 100ms，说明物理 IO 或临时表空间压力大（查 “IO Stat by Filetype” 和 “Temporary Tablespace Usage”）
注意：DB CPU 值低 ≠ CPU 没瓶颈。如果大量会话卡在 latch: shared pool，它们在 OS 层面可能表现为 runnable queue（vmstat r 值高），但 Oracle 统计为 latch 等待而非 CPU 时间。
别忽略 AAS 计算背后的快照有效性
AAS 值可靠的前提是两个快照间实例没重启、没强制清空 SGA。否则 AWR 会报错：“ERROR: Invalid snapshot range”，或生成的报告中 DB Time 出现负值、Elapsed Time 异常小（如几秒）。实操中容易踩的坑：
- 用
@?/rdbms/admin/awrrpt.sql时手动输错Snap Id，选到跨 instance 或跨 RAC node 的快照 - 在 RAC 环境下未指定
instance_number，脚本默认用当前连接实例，但报告却混入其他节点数据（看报告头 “Instances in this Workload Repository schema” 是否只列一个） - 11g 默认保留 8 天 AWR 数据，但若手工执行过
exec dbms_workload_repository.modify_snapshot_settings(retention=>4320)（单位分钟），旧快照可能已被清理，导致无法选取业务高峰期的对比点
真正难的是把 AAS 数值和业务语义对齐：AAS=3.2 是高还是低？得先知道这个库日常峰值就是 2.8，还是说平时只有 0.3——没有基线，所有数字都是孤岛。
