首先需要达成一个共识：当AAS（平均活跃会话数）超过CPU核数时，基本上可以直接触发告警机制。其背后的逻辑其实非常清晰直接——AAS衡量的是单位时间内的并发负载，其计算方式为DB Time除以Elapsed Time，单位是“等效并发会话数”。一旦这个数值大于物理CPU的核心数量，就意味着数据库在单位时间内需要的服务能力，已经超过了硬件所能提供的上限。
值得警惕的是，在这种情况下，必然会有会话在排队等待CPU调度，响应延迟也就随之而来。这不仅仅是一个理论上的阈值，而是一个硬性的性能瓶颈信号。即使操作系统层面的load看起来并不高，top命令中的%us也没有达到100%，只要AAS持续高于CPU核数，就说明前台会话已经在争抢CPU时间片。Oracle并不会将空闲时间纳入统计，因此这个数值没有任何水分。
为什么不能用DB Time或OS load替代AAS进行判断
不少技术人员习惯用DB Time来判断负载高低，但必须注意，DB Time是一个绝对时间的累加值，它完全没有考虑系统的容量规格。举例来说，在60分钟内DB Time合计为480分钟，单独看这个数值似乎比较高，但如果服务器拥有16个核心，那么AAS=480/60=8，实际上负载仍在可接受范围内。反过来，如果AAS达到22而CPU只有8核，那就意味着大约有14个会话正在排队等待处理。
OS load就更不可靠了。它涵盖了D状态（不可中断睡眠，例如磁盘IO卡住）、后台进程，甚至还包括僵尸进程。而AAS只统计前台会话的活跃时间——即ON CPU或WAITING状态，与用户能够感受到的响应延迟高度相关。因此，千万不要将v$osstat中的LOAD误当作AAS来使用。
- 跨RAC实例时，每个实例的AAS必须单独与它自身的CPU核数进行比对，切勿简单加总
- 如果DB Time上升但AAS正常，那么大概率是慢SQL导致单次执行时间延长，而非真正的并发负载升高
查询AAS的正确方法：避开首页Top 5事件的潜在误导
AWR报告首页的“Top 5 Timed Events”往往只是呈现结果，而不是问题的根本原因。例如，db file sequential read排在首位，可能只是因为某条逻辑读量极大的SQL在大量进行索引扫描——问题根源在于SQL本身，而非磁盘。
真正应该关注的是报告中“Average Active Sessions”图表下方的两个数值：Begin Snap和End Snap对应的AAS均值（注意不是平均值的平均值）。然后通过cat /proc/cpuinfo | grep processor | wc -l或查询v$osstat来确认实际的CPU核心数量。
- 如果图表中某5分钟区间的AAS突然冲到18，而其余时间稳定在3，那就应当重点分析那5分钟内的具体活动
- 要是AAS长期高于CPU核数，但Top Events中全是SQL*Net message from client，这很可能意味着僵尸会话堆积，而非真正的繁忙
- 请记住，“Instance Efficiency Percentages”部分并不包含AAS值，查看它对判断并无帮助
ASH中的Active Sessions与AAS并非同一概念
在术语上存在一个容易混淆的点：v$active_session_history中的“Active Sessions”是瞬时快照数（每秒采样一次），而AWR报告中的Average Active Sessions则是该时间段内的平均值。前者波动较大，后者更为平稳，因此报警阈值应当基于后者来设定。
此外，ASH本身并不记录STATUS='INACTIVE'的会话，因此你看到的“Active Sessions”数值永远是偏低的。这也解释了为什么当AAS偏高，而v$session中STATUS='INACTIVE'的会话数量远超预期时，需要立刻怀疑是否存在连接泄漏。
判断真实负载时必须进行交叉验证：如果AAS偏高，同时v$session中LAST_CALL_ET大于3600的INACTIVE会话数量较多——这种情况应首先检查应用端的连接池配置，而不是急于调整数据库参数。
