AAS高不表示数据库真忙，而是单位时间内非空闲前台会话的加权平均值；需结合DB Time、Top 5 Timed Events、等待事件类型及业务指标综合判断根因。
aas值高不等于数据库真忙，它只是反映“正在干活”的会话平均数量。oracle 19c 的 average active sessions（aas）是awr报告里最常被误读的指标之一——它不是并发连接数，也不是os线程数，而是单位时间内“处于非空闲状态”的前台会话的加权平均值。如果你看到 aas = 42，而服务器只有 16 个 cpu，第一反应不该是“cpu 肯定爆了”，而应立刻查 top 5 timed events 和 db time 构成。
看AAS前先确认DB Time是否真实膨胀
AAS 的计算公式是 DB Time / Elapsed Time，所以它本质是 DB Time 的密度指标。如果 DB Time 本身虚高（比如大量短时等待堆叠、或采样偏差），AAS 就会失真。
- 检查
DB Time是否远超Elapsed Time × NUM_CPUS：例如 Elapsed=60 分钟、NUM_CPUS=32 → 理论最大 DB Time ≈ 1920 分钟；若报告中 DB Time 达 3200 分钟，说明存在显著排队或等待累积 - 注意快照间隔是否过长：默认 1 小时快照可能掩盖尖峰。若业务有秒级抖动（如批量作业每5分钟触发一次），单靠 AAS 会平滑掉真实压力点
- 排除后台进程干扰：
DB Time包含所有前台会话，但 AAS 统计不含后台进程（如 DBWR、LGWR）。若大量逻辑读来自物化视图刷新等后台任务，AAS 不体现，但 DB Time 会涨
区分“真活跃”和“假活跃”：从等待事件反推AAS成分
AAS 高的根源一定落在 Top 5 Timed Events 里。不同等待类型对系统的影响天差地别：
-
DB CPU占比 > 60%：AAS 高 = 真实计算压力，重点查SQL ordered by CPU Time，关注未绑定变量、全表扫描、PL/SQL 循环嵌套 -
db file sequential read或db file scattered read主导：AAS 高 = I/O 瓶颈拖慢会话响应，不是 CPU 不够，而是磁盘吞吐或缓存命中率（Buffer Hit %）不足 -
enq: TX - row lock contention或latch: cache buffers chains：AAS 高 = 并发争用，会话在排队等资源，实际工作时间少、等待时间长 —— 此时优化锁粒度或索引比加 CPU 更有效 - 大量
SQL*Net message from client出现在 Top 5：AAS 被“客户端停顿”拉高，本质是应用层未及时取走结果集，数据库空等，和数据库负载无关
对比Load Profile里的Transactions和Executes看业务节奏
AAS 是“瞬时活跃度”，但业务负载要看节奏是否合理：
Remix V2 Meta Sessions Review
下载
审查 Remix v2 代码中的 v1 形态 meta 导出（v2 中为破坏性变更），cookie 安全漏洞（httpOnly、secure、密钥轮换），认证门位于错误层级，以及其他
- 若
Transactions per Second稳定在 50，Executes per Second却高达 800，说明单事务执行大量 SQL（如循环插入、未批量提交），会人为抬高 AAS —— 这是应用层问题，不是数据库配置问题 -
Logons per Second> 2：频繁建连/断连，导致大量硬解析（Hard Parses per Second），既推高 AAS，又浪费 shared pool。应检查连接池配置或启用session_cached_cursors -
Physical Reads per Second持续 >Logical Reads per Second× 0.2：表明缓存效率差，大量会话反复触发物理读，AAS 被 I/O 延迟撑大，此时调db_cache_size或优化热点 SQL 更直接
真正危险的 AAS 高，是 DB CPU + DB Time + Top SQL CPU Time 三者同步上扬，且集中在少数几条语句上。其余情况，AAS 更像一个“告警触发器”，而不是根因——它告诉你“有事发生”，但具体什么事，得往下翻三页报告，盯住等待事件和 SQL 排行榜。忽略这点，容易把 I/O 等待当成 CPU 过载，徒劳升级硬件。
