awr中db cpu高不等于cpu过载，aas持续超过物理cpu核数才是排队过载的硬指标；aas= db time/elapsed time，需与v$osstat中num_cpus对比，oltp下aas>5或>1.2×cpu核数即需介入。
AWR 里 DB CPU 高 ≠ CPU 过载，AAS > CPU 核数才是排队过载的硬指标。
看 AAS 是否持续超物理核数
AAS（Average Active Sessions）= DB Time / Elapsed Time，它直接反映数据库内“正在干活”的会话平均数量。这个值必须和服务器逻辑 CPU 总数比：
- 查真实核数：
SELECT value FROM v$osstat WHERE stat_name = 'NUM_CPUS'（不是/proc/cpuinfo里看到的线程数，v$osstat 才是 Oracle 认的） - OLTP 场景下 AAS 持续 > 5 就该介入；> CPU 核数 × 1.2 是明确排队信号（如 16 核机器 AAS = 20，说明平均时刻有 4 个请求在队列里等）
- AAS = 0.3 但用户喊慢？大概率是单条 SQL 延迟高、网络抖动或应用超时设太短，不是数据库级瓶颈
拆解 DB Time 构成：CPU 占比低≠没问题
DB Time 是前台会话总耗时，由 DB CPU + 所有非空闲等待时间叠加而成。只看占比会漏掉关键线索：
- 若
DB Time= 2800 分钟，Elapsed Time= 60 分钟，CPU 核数 = 16 → 理论上限是 960 分钟，实际超 2.9 倍，说明资源争抢已成常态 -
DB CPU占比仅 25%？那 75% 时间花在等待上，必须往下翻Top 5 Timed Foreground Events，而不是盯着 CPU - 特别警惕
latch: shared pool或library cache lock进 Top 5——这代表硬解析或共享池争用，CPU 被耗在“找计划”上，不是执行 SQL
交叉验证 OS 层 CPU 真实负载
Oracle 的 DB CPU 只统计自己进程的 CPU 时间，主机上还有备份、监控 agent、系统服务等在抢资源。得看 AWR 里的操作系统统计：
- 算真实利用率：
BUSY_TIME/ (BUSY_TIME+IDLE_TIME)，不是看绝对值（比如BUSY_TIME=12933418 不代表忙，要结合IDLE_TIME=269466546 算出实际约 4.6%） -
IOWAIT_TIME突增（如从 50 跳到 15000）？说明 CPU 大量时间在等磁盘，此时BUSY_TIME低是假象 -
LOAD值持续 >NUM_CPUS（比如 LOAD=120，NUM_CPUS=112）？哪怕 CPU 利用率才 30%，运行队列也已在堆积，响应延迟必然出现
别信 AWR 小时级快照的“平滑假象”
AWR 默认每小时采一次，根本抓不住秒级尖峰。某 SQL 每分钟跑一次、每次吃 5 秒 CPU，AWR 可能只记到 5 秒，而实际每秒都在施压：
- 实时抓取：
mpstat -P ALL 1 5看各核瞬时分布，pidstat -u 1 5看 oracle 进程每秒占用 - 查内存级信号：
V$SYSMETRIC中CPU Usage Per Sec（单位是厘秒），比 AWR 的累计值更敏感 - RAC 环境下必须分实例看 AAS 和 DB Time，用
awrrpti.sql生成 per-instance 报告，否则节点不均会被平均掉
真正容易被忽略的是：DB Time 超限和 AAS 过高，往往不是某个 SQL 突然变慢，而是大量中低频 SQL 同时小幅劣化（比如 plan_hash_value 批量漂移、NLS 参数不一致导致硬解析泛滥），这种“温水煮青蛙”式压力，在 Top SQL 排名里根本不显眼。
