aas是数据库真实负载的瞬时压力密度指标，计算公式为db time / elapsed time，直接决定cpu、内存和连接池最小配置下限；它剔除空闲会话干扰，反映实际资源占用，是容量规划与硬件采购的硬约束而非参考值。
平均活动会话数（average active sessions, aas）不是“并发用户数”的简单计数，而是数据库真实负载的瞬时压力密度指标——它直接决定cpu、内存和连接池的最小配置下限。
为什么AAS比Sessions或User Calls更关键
AAS是单位时间内真正占用CPU或等待资源的会话均值，计算公式为 DB Time / Elapsed Time。它天然消除了空闲会话干扰：100个连接池里只有3个在干活，AAS≈3；而Sessions字段可能显示98。容量规划若只看Sessions，会误判为需扩容连接数而非优化SQL或加CPU。
- 当AAS持续 > CPU核心数 × 0.75，说明CPU已开始排队，响应延迟上升是必然结果
- AAS突增但User Calls未同比放大，大概率是单条SQL执行计划劣化（如全表扫描替代索引查找）
- RAC环境下某节点AAS占比超总AAS的60%，意味着负载不均，盲目扩容整集群只会浪费资源
AAS与硬件采购的换算关系
它不是参考值，是硬约束。例如：
- 报告中AAS = 12.4，且业务峰值稳定在该水平 → 至少需要16核CPU（预留20%余量），低于此值必然出现
resmgr:cpu quantum或latch free争用 - AAS在15分钟内从2.1飙升至18.7，同时
DB Time中db file sequential read占比超40% → 不是加CPU，而是必须优化IO路径（比如调整db_file_multiblock_read_count或重建索引） - AWR中AAS曲线与应用层QPS曲线斜率不一致（如QPS翻倍但AAS仅+30%）→ 暗示连接复用率提升或批处理逻辑生效，此时扩容优先级应低于代码层优化
常见误读和陷阱
AAS容易被表面数字误导，关键要看它背后的时间粒度和聚合方式：
- 用2小时快照生成报告，但实际业务高峰仅集中在其中12分钟 → 报告AAS被严重稀释（如真实峰值AAS=35，报告却显示AAS=8.2），按此扩容会直接导致上线即卡顿
- 默认AWR聚合所有实例，RAC环境未启用
awr_report_html的instance_number参数 → 看不到单节点AAS爆表，误以为负载均衡 - ADDM建议“增加SGA”，但AAS在SGA增大后不降反升 → 实际是硬解析过多导致
library cache lock等待，应查Hard parses/s而非调内存
真正决定扩容节奏的，从来不是某个峰值数字，而是AAS在不同业务场景下的稳定性——连续3天早高峰AAS标准差
