AWR中HOST CPU指标无法反映虚拟化超卖，需结合LOAD、IOWAIT_TIME、BUSY_TIME/IDLE_TIME比例及宿主机数据交叉验证；因vCPU调度延迟、节流、steal_time缺失等导致GV$OSSTAT失真，单看CPU利用率无意义。
Host CPU指标在AWR中不能直接反映虚拟化超卖，必须结合LOAD、IOWAIT_TIME、BUSY_TIME/IDLE_TIME比例与宿主机层数据交叉验证——单看AWR里的“CPU利用率”数值毫无意义。
为什么BUSY_TIME和IDLE_TIME比例在虚拟机里更不可信
虚拟机操作系统看到的BUSY_TIME和IDLE_TIME是vCPU被调度器实际分配到物理核上的时间，但不包含vCPU就绪但等待调度（runqueue wait）或被节流（throttled）的时间。Oracle 19c默认采集的GV$OSSTAT中这些值，在VMware/Oracle VM/KVM等环境下常出现以下失真：
-
IDLE_TIME被虚高：当vCPU被hypervisor挂起（如内存ballooning触发、CPU limit生效），guest OS仍会计为idle，导致BUSY_TIME / (BUSY_TIME + IDLE_TIME)偏低，掩盖真实争用 -
BUSY_TIME被截断：某些hypervisor对vCPU时间戳做频率缩放（如Intel TSC scaling），导致累计值溢出或跳变，AWR快照间差值异常（比如上一快照BUSY_TIME=12000000，下一快照变成500000） - 无法体现
steal_time：Linux/proc/stat中的steal字段（vCPU时间被其他VM抢占）根本不会被Oracle采集进GV$OSSTAT，AWR里完全看不到
必须查的三个关键信号：LOAD、IOWAIT、steal_time缺失
判断是否超卖，重点不是“CPU忙不忙”，而是“有没有被抢、有没有被卡、有没有等磁盘”。这三个信号在AWR里有迹可循，但需人工补全：
-
LOAD持续高于vCPU数量：比如分配了8个vCPU，但AWR中LOAD（1分钟值）稳定在12以上，且IOWAIT_TIME占比BUSY_TIME不足5% → 高概率是vCPU就绪队列堆积，即超卖或CPU limit过严 -
IOWAIT_TIME飙升但Physical reads/sec没涨：说明不是磁盘慢，而是vCPU频繁被切走，IO completion回调迟迟得不到执行机会 → 典型的CPU节流表现 - 手动验证
steal_time：登录宿主机执行cat /proc/stat | grep '^cpu '，看第8个字段（steal）是否持续增长；若该值非零而AWR中GV$OSSTAT无对应统计项，说明hypervisor正在回收CPU资源
怎么绕过AWR局限做交叉验证
AWR本身不提供虚拟化层视角，必须跳出数据库查宿主机和监控系统：
- 查VMware vCenter：看该VM的
%RDY（Ready time）是否持续>10%，>20%即严重超卖；同时看%CSTP（Co-stop）是否非零，表示vCPU被强制同步停顿 - 查KVM宿主机：
virsh domstats <vm-name></vm-name>输出中的cpu.time和cpu.wait比值，若cpu.wait / cpu.time > 0.15，说明调度延迟已影响业务 - 用
mpstat -P ALL 1 5在guest内运行：如果某vCPU的%idle忽高忽低（如0%→99%→0%），而%iowait稳定在0，大概率是被hypervisor throttle，不是应用问题 - 对比AWR快照间隔与宿主机监控粒度：若Zabbix/Prometheus记录的CPU使用率峰值达95%，但同一时段AWR报告里
BUSY_TIME/(BUSY_TIME+IDLE_TIME)仅65%，那差值就是steal或throttle时间
真正危险的不是CPU满载，而是AWR显示“一切正常”却线上响应抖动——那往往意味着vCPU调度权已被hypervisor收回，而数据库对此一无所知。务必把GV$OSSTAT当参考，而非依据；所有结论都要用宿主机指标反向打标。
