AWR中判断Swap是否真在活动应关注PI和PO指标而非SWAP_FREE_BYTES；PI/PO持续非零（尤其>100 KB/s）表明频繁换页，若二者近似同步跳动则为抖动式换页；需结合/proc等系统工具定位具体换页进程。
AWR里怎么看Swap是否真在活动
只看swap_free_bytes数值大，不代表没换页——它只是“空闲swap容量”，不是“换页行为发生量”。真正危险的信号藏在pi（page in）和po（page out）两个指标里。
打开AWR报告的Operating System Statistics部分，重点盯这两列：
-
PI和PO在快照周期内持续非零（尤其>100 KB/s），说明内核正频繁搬运内存页 - 若
PI≈PO且数值同步跳动，基本可断定是“抖动式换页”（thrashing） -
FREE_MEMORY_BYTES缓慢下降 +INACTIVE_MEMORY_BYTES不升反降，暗示内存被长期占用却未释放（比如PGA泄漏、未关闭的大游标）
DB CPU高 ≠ 主机内存压力大，但PI/PO高一定有问题
DB CPU只统计Oracle进程在CPU上执行的时间，和Swap无关。而PI/PO是操作系统内核级计数器，反映真实物理内存短缺后的补救动作。
常见误判场景：
- 看到
DB CPU占总DB Time 70%，就去调优SQL——但此时PI=42,819,PO=39,560，说明瓶颈其实在内存换页，SQL再快也得等页换回来 -
FREE_MEMORY_BYTES=150GB，就认为“内存够用”——其实Active(anon)内存已断崖下跌，大量匿名页被标记为可换出，只等内核调度 - 忽略
NUM_CPUS=112但LOAD持续>120，这表示运行队列积压，其中一部分等待正是因缺页中断（page fault）引发的
AMM/ASMM模式下Swap更容易被意外触发
Oracle启用memory_target（AMM）或sga_target（ASMM）时，会动态调整SGA大小。但Linux内核并不知道这是Oracle的关键内存，只要满足vm.swappiness阈值（默认60），就会把刚分配的SGA页swap out。
这不是配置错误，而是机制冲突：
- Oracle申请内存 → 内核分配page → 内核根据LRU和swappiness决定换出 → Oracle访问该页触发major page fault → 延迟飙升
- 即使
LOCK_SGA设为true，对AMM无效；只有手动内存管理（manual）+HUGEPAGES+vm.nr_hugepages配足，才能绕过此问题 - 检查是否启用了AMM：
SELECT value FROM v$parameter WHERE name = 'memory_target'，若返回非0值，就得警惕Swap联动风险
光看AWR不够，必须结合/proc定位具体进程
AWR不提供谁在换页，只给总量。要揪出元凶，得登录主机跑命令：
- 查整体Swap使用：
free -h或cat /proc/meminfo | grep -i swap - 找Swap大户：
smem -s swap -r | head -10（按Swap使用量倒序） - 看Oracle进程细节：
grep -i swap /proc/$(pgrep -f ora_pmon)/smaps 2>/dev/null，关注Swap:行数值 - 确认是否HugePages生效：
grep -i huge /proc/meminfo，若HugePages_Free≈HugePages_Total，说明没被使用
最常被忽略的一点：Swap活动往往始于某个非Oracle进程（如Python脚本加载大模型、Java监控agent内存泄漏），它先吃掉大量anon内存，把内核逼到换页临界点，Oracle才被动卷入。所以别一上来就调sga_max_size。
