AWR中判断CPU是否真高需计算BUSY_TIME/(BUSY_TIME+IDLE_TIME)占比，而非单看绝对值；IOWAIT_TIME飙升、LOAD持续超NUM_CPUS、PI/PO频繁交换、Active(anon)断崖下跌等才是真实瓶颈信号。
看懂 AWR 里的 Host CPU 使用是否真高
awr 报告里 busy_time 和 idle_time 看着高或低，不能直接等价于“cpu 瓶颈”。关键得算占比：busy_time / (busy_time + idle_time) 才是真实 cpu 利用率。比如你看到 busy_time=12,933,418、idle_time=269,466,546，实际利用率仅约 4.6%，远没到警戒线（通常 >80% 才需干预）。
容易踩的坑：
-
DB CPU等待事件高 ≠ 主机 CPU 高——它只反映数据库进程在 CPU 上执行的时间，但主机可能还有大量非 Oracle 进程（如备份脚本、监控 agent）在抢资源，这部分不会体现在DB CPU里 - 忽略
IOWAIT_TIME：如果它突然飙升（比如从几十升到上万），即使BUSY_TIME不高，也说明 CPU 大量时间在等磁盘，本质是 I/O 卡住导致的“假性空闲” - 不比对
LOAD：AWR 的LOAD值（如从 4 升到 9）反映的是运行队列长度，若持续 > CPU 核数（NUM_CPUS=112），哪怕 CPU 利用率才 30%，也可能出现任务排队、响应延迟
识别内存分页（paging）是否已成问题
真正危险的信号不是“用了 Swap”，而是“正在频繁换入换出”——这在 AWR 的 Operating System Statistics 里体现为 PI（page in）和 PO（page out）持续非零，尤其当它们数值接近或超过每秒百 KB 级别时，说明内核正疲于奔命地搬数据。
常见错误现象：
- 误把
SWAP_FREE_BYTES=68,719,472,640（64GB）当成“内存很充裕”——其实只要PI/PO在动，就代表物理内存已不够用，只是 Swap 空间还没耗尽 - 忽略
INACTIVE_MEMORY_BYTES走势：如果它持续减少而FREE_MEMORY_BYTES没同步上升，大概率是内存被进程长期 hold 住（比如 PGA 泄漏、未释放的大对象），而非真正释放了 - 在 Linux/AIX 上查不到具体谁在换页：AWR 不提供进程级 Swap 使用明细，必须结合
/proc/$pid/smaps中的Swap:行或smem -s swap手动定位
Swap 活动与 Oracle 内存参数的隐性冲突
Oracle 实例若启用了 AMM（memory_target）或 ASMM（sga_target），而主机又开了 Swap，就可能出现“Oracle 想扩 SGA，系统却把刚分配的页 swapped out”的恶性循环。这不是配置错，而是内核 OOM killer 和 Oracle 内存管理策略的底层博弈。
实操建议：
- 检查当前模式：
SELECT CASE WHEN mt.value>0 THEN 'AMM' WHEN st.value>0 THEN 'ASMM' ELSE 'manual' END FROM v$parameter mt, v$parameter st WHERE mt.name='memory_target' AND st.name='sga_target' - 若用 AMM，务必禁用大页（
use_large_pages=FALSE）——否则 AMM 会绕过大页机制，反而加剧分页 - 确认
vm.swappiness值：Linux 默认是 60，对数据库应设为1或0（仅在绝对必要时 swap），避免内核主动回收 Oracle 进程页 - 不要只看
PGA_AGGREGATE_TARGET：当V$PGASTAT中bytes processed远大于cache hit percentage，说明大量排序/哈希被迫落盘，间接推高 Swap 活动
跨平台验证：从 AWR 跳到主机命令补全真相
AWR 是快照，有滞后性；主机命令是实时毛刺探测器。两者必须交叉验证，否则你会在“报告说一切正常”和“用户喊慢”之间反复横跳。
对应关系要记牢：
- AIX 的
vmstat 1 5输出中，pi/po列 ≈ AWR 的PI/PO；avm持续 > 物理内存 80% 且fresvmon -G - Linux 的
esxtop（ESXi）或top（按f→ 选SWAP字段）能直接看到每个oracle进程的 Swap 使用量，比 AWR 精确到进程级 - Windows 任务管理器“性能”页的“提交大小”减去“内存使用量”≈ 当前 Swap 占用，若该值 > 2GB 且增长快，别信 AWR 里那句“
SWAP_FREE_BYTES充足”
最常被忽略的一点：AWR 不采集 /proc/meminfo 中的 Inactive(file) 和 Active(anon)，而这俩才是判断 Oracle SGA 是否被内核当作“可回收缓存”干掉的关键证据——一旦 Active(anon) 断崖下跌，基本就是 SGA 被悄悄 swap out 了。
