为什么Oracle ASH中Active Sessions数值超过CPU核数即报警

AAS超过CPU核数直接报警，因其表示单位时间内活跃会话数已超物理并行能力，必然导致排队和响应延迟；而DB Time是绝对时间总和、OS load含非前台进程，均无法准确反映用户感知的并发负载。

Active Sessions 超过 CPU 核数为什么直接报警

因为 aas（average active sessions）是归一化后的并发负载度量，它等于 db time / elapsed time，单位是“等效并发会话数”。当 aas > cpu 核数，说明数据库在单位时间内需要的服务时间，已经超出物理 cpu 的并行处理能力——必然有会话在排队等待 cpu 调度，响应延迟就此产生。

这不是理论阈值，而是硬性瓶颈信号：哪怕 os load 看起来不高、top 里 %us 也没到 100%，只要 AAS 持续高于核数，就代表前台会话实际在争抢 CPU 时间片。Oracle 不会把空闲时间算进去，所以这个值没水分。

为什么不能用 DB Time 或 OS load 替代 AAS 判断

DB Time 是绝对时间总和，不考虑系统容量。比如 60 分钟内 DB Time = 480 分钟，单独看很高，但若服务器有 16 核，AAS = 480/60 = 8，其实负载尚可；反之 AAS = 22 而只有 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 长期 > 核数，但 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 会话多 → 先查应用端连接池配置，而不是优化 SQL。