AWR本身不能直接判定是否发生严重内存交换，真正要确认“严重”必须结合PI和PO的持续速率（如>100 KB/s）、INACTIVE_MEMORY_BYTES持续下降趋势，以及/proc等主机层进程级Swap定位。
awr本身不能直接判定是否发生严重内存交换，它只反映总量级swap活动；真正要确认“严重”，必须结合pi和po的持续速率、inactive_memory_bytes走势，以及主机层进程级swap定位。
看AWR里的PI和PO是否持续非零且量级异常
Operating System Statistics部分的PI（page in）和PO（page out）是唯一能从AWR中直接抓取的换页信号。它们不是“用了多少Swap”，而是“每秒搬多少数据”：
-
PI和PO在报告周期内长期 > 0（比如连续1小时每分钟都非零），说明内核一直在做换页，不是偶发抖动 - 单次快照里
PI+PO总和 > 100 KB/s（即每秒百KB级），就已进入危险区；> 500 KB/s 基本可断定物理内存严重不足 - 注意单位：AWR里数值是累计值，需手动除以快照间隔（秒）算出速率。例如快照间隔3600秒，
PO=1.8e9字节 → 1.8e9 / 3600 ≈ 500 KB/s - 别只看
SWAP_FREE_BYTES——它大不代表安全，64GB空闲Swap下PI/PO持续跑200 KB/s，照样是系统在慢性窒息
对比FREE_MEMORY_BYTES和INACTIVE_MEMORY_BYTES的同步变化
这两项在Operating System Statistics里并列出现，它们的剪刀差比绝对值更有诊断价值：
- 如果
FREE_MEMORY_BYTES没明显上升，但INACTIVE_MEMORY_BYTES持续下降（比如1小时内掉2GB），说明内存被进程长期占用后未释放，不是“暂时忙”，而是“占着不放” - 典型陷阱：看到
FREE_MEMORY_BYTES还有150GB就放松警惕，却忽略INACTIVE_MEMORY_BYTES已从61GB跌到45GB——这往往对应PGA泄漏或未关闭的大游标 - 这种走势+高
PI/PO，基本可排除AMM/ASMM动态调整的假象，指向真实内存压力
查memory_target是否启用，确认Swap问题是否由机制冲突引发
Oracle启用了AMM（memory_target > 0）时，Swap活跃大概率不是配置低，而是内核与Oracle内存管理策略打架：
- 执行
SELECT value FROM v$parameter WHERE name = 'memory_target'，若返回非零值，就要警惕“Oracle刚分配页，内核立刻swap out”的恶性循环 - AMM模式下
LOCK_SGA无效，vm.swappiness=1也压不住——根本解法是切回手动内存管理+HUGEPAGES，而非调低swappiness - AWR里若同时出现高
PI/PO和频繁SGA resize（见SGA Resize Operations小节），就是典型机制冲突证据
用ps和/proc/$pid/smaps定位具体进程
AWR给不出“谁在换页”，这一步必须登录主机补全链路：
- 运行
ps -eo pid,vsz,rss,comm --sort=-rss | head -10，看Oracle进程RSS是否随时间单向增长（比如1小时内涨3GB） - 对RSS最高的Oracle进程，查
cat /proc/<pid>/smaps | grep -i swap</pid>，若Swap:行数值持续上升（如从0→200MB→800MB），就是该进程在触发换页 - 特别注意
ora_pmon_、ora_mmon_这类后台进程RSS异常升高——常指向AWR自身处理环节泄漏，此时要查V$AW_ALLOCATE_OP中STATUS='LEAKED'记录
真正难的不是发现PI/PO高，而是区分它是AMM机制下的必然抖动，还是PGA泄漏或外部进程吃光内存导致的硬短缺——后者必须跳出AWR，在/proc里动手验证。
