CPU Utilization % 是唯一反映 CPU 实际忙闲程度的指标，直接来自 /proc/stat，计算用户态+系统态时间占比；它与 Load Average 本质不同，后者含 I/O 等待进程，不反映 CPU 真实负载。
cpu utilization % 是唯一反映 cpu 实际忙闲程度的指标
它直接来自 /proc/stat，计算的是用户态 + 系统态 CPU 时间占总可用时间的比例。和 Load Average 完全不是一回事——后者是就绪队列长度 + 不可中断进程数的平均值，哪怕 CPU 空闲，D 状态 I/O 等待多也会拉高 Load。
实操建议：
- 持续 > 90%：CPU 真饱和，优先查
v$session中ON CPU的会话，尤其是ora_mmon_*、ora_mmnl_*这类后台进程 - 长期在 30%~60% 但 Load Average > CPU 核数 ×2：大概率是 I/O 卡住或锁争用，不是 CPU 问题，别盲目加核
- AWR 默认 1 小时采样一次，会漏掉短时尖峰；真要定位瞬时飙高，得结合
ASH（v$active_session_history）按秒级查
它受 STATISTICS_LEVEL 和 AWR 快照策略直接影响
STATISTICS_LEVEL = 'TYPICAL'（11g 默认值）就足以触发 MMON 每小时快照、MMNL 每分钟刷 ASH，这些后台任务本身就会吃 CPU。尤其刚重启后 ASH buffer 积压，或快照间隔设成 15 分钟、保留 60 天，MMON 扫描历史数据量暴增，CPU Utilization 就会异常偏高。
验证方式：
- 查
v$parameter确认statistics_level当前值 - 查
dba_scheduler_jobs是否启用了ORA$AT_OS_OPT_SY_*类自动调优任务 - 临时调低快照频率或关闭部分自动任务（如禁用 SQL Tuning Advisor），观察 CPU Utilization 是否回落
别把它和资源管理里的 CPU 份额混淆
比如 Solaris Zones 或 Oracle Resource Manager 里配的 cpu_shares，只是争用时的相对权重，不等于实际使用率。一个只配了 10% 份额的项目，在空闲系统上照样能跑满 100% CPU——所以 OS Stat 里的 CPU Utilization % 才是真实水位线，份额配置再细，也掩盖不了底层物理 CPU 是否真的被榨干。
真正容易被忽略的是：这个值只告诉你“CPU 在忙什么”，但不告诉你“为什么忙”。后台任务吃高 CPU 很可能源于统计信息过期、执行计划劣化、或某张大表没分区导致 MMNL 刷基线时反复全表扫描——得顺着 SQL_ID 和 event 往下挖，不能只盯着百分比数字看。
