Oracle如何通过AWR对比分析，准确判断内存使用趋势中的潜在泄漏问题？
- 内容介绍
- 文章标签
- 相关推荐
本文共计841个文字，预计阅读时间需要4分钟。
相关专题：
awr本身不能直接判断内存泄漏，它只反映sga/pga的使用趋势；真要确认泄漏，得结合v$aw_allocate_op、v$sga_dynamic_components和操作系统级观察。
AWR里看内存趋势只能提示异常，不是诊断依据
AWR报告中的“Memory Usage”部分（尤其在Instance Overview和Resource Usage章节）会展示SGA/PGA的平均/峰值使用量，但这些数值是采样快照，不体现内存是否被持续占用后未释放。比如你看到PGA Alloc %从40%缓慢爬升到95%并长期卡住，这算一个信号，但无法区分是业务负载自然增长，还是某进程不断malloc却没free。
常见误判现象：
- 把
PGA memory used持续升高当成泄漏，实际是排序/哈希连接临时段暴涨，SQL结束后会自动释放 - 看到
Shared Pool Free Memory下降就紧张，忽略了shared pool内部碎片或cursor aging机制 - 对比两个AWR报告发现
Buffer Cache Hit Ratio下降，误以为内存不足，其实是逻辑读暴增导致命中率被动稀释
真正该盯的动态视图和指标
内存泄漏必须落在“分配了但没归还”的行为上，Oracle里能体现这点的只有运行时分配记录：
-
V$AW_ALLOCATE_OP：只在AWR快照生成、聚合、清理过程中有数据，若某次OP_TYPE为SNAPSHOT后，ALLOCATED_BYTES长期不回落，且FREE_BYTES始终为0，就是AWR自身处理环节的泄漏线索 -
V$SGA_DYNAMIC_COMPONENTS：重点看CURRENT_SIZE与MIN_SIZE的差值。如果某个组件（如shared_pool）CURRENT_SIZE持续大于MIN_SIZE且不缩容，再配合V$SGASTAT中free memory持续萎缩，才值得怀疑 - 操作系统层：
ps -eo pid,vsz,rss,comm --sort=-rss | head -10查Oracle进程RSS是否随时间单向增长，比AWR更直接
用AWR做趋势对比时的关键操作点
如果你坚持用AWR做初步筛查，必须控制变量，否则对比毫无意义：
- 选相同工作负载时段：比如都选每天上午9:00–10:00，避开备份、ETL等干扰任务
- 固定快照间隔：用
DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT手动打快照，避免默认1小时间隔被跳过 - 对比具体字段而非笼统描述：不要只看“High Memory Usage”警告，要提取
PGA Aggr Used、SGA Target、Buffer Cache Size三列数值，算差值百分比 - 排除AMM/ASMM干扰：若
memory_target > 0，Oracle会动态重分配SGA/PGA，此时趋势波动属正常行为，V$MEMORY_TARGET_ADVICE比AWR更有参考价值
最容易被忽略的泄漏场景
真正的泄漏往往藏在非典型路径里：
- PL/SQL中用
DBMS_SQL.OPEN_CURSOR打开游标但没CLOSE_CURSOR，会导致shared pool里cursor heap持续膨胀，AWR里表现为library cache: mutex X等待上升+ shared pool free memory归零 - 外部过程（Extproc）调用C代码分配内存后崩溃退出，Oracle无法回收那块PGA，
V$PROCESS里对应进程的PGA_USED_MEM会锁死在高位 - AWR保留策略设为
NULL或过大（如365天），WRH$_ACTIVE_SESSION_HISTORY表不断写入但清理线程卡住，最终撑爆SYSAUX表空间——这不是内存泄漏，但症状高度相似
AWR趋势只是望远镜，真要动手解剖，得切开进程、查堆栈、盯分配链。别让“看起来像”耽误了定位黄金时间。
本文共计841个文字，预计阅读时间需要4分钟。
相关专题：
awr本身不能直接判断内存泄漏，它只反映sga/pga的使用趋势；真要确认泄漏，得结合v$aw_allocate_op、v$sga_dynamic_components和操作系统级观察。
AWR里看内存趋势只能提示异常，不是诊断依据
AWR报告中的“Memory Usage”部分（尤其在Instance Overview和Resource Usage章节）会展示SGA/PGA的平均/峰值使用量，但这些数值是采样快照，不体现内存是否被持续占用后未释放。比如你看到PGA Alloc %从40%缓慢爬升到95%并长期卡住，这算一个信号，但无法区分是业务负载自然增长，还是某进程不断malloc却没free。
常见误判现象：
- 把
PGA memory used持续升高当成泄漏，实际是排序/哈希连接临时段暴涨，SQL结束后会自动释放 - 看到
Shared Pool Free Memory下降就紧张，忽略了shared pool内部碎片或cursor aging机制 - 对比两个AWR报告发现
Buffer Cache Hit Ratio下降，误以为内存不足，其实是逻辑读暴增导致命中率被动稀释
真正该盯的动态视图和指标
内存泄漏必须落在“分配了但没归还”的行为上，Oracle里能体现这点的只有运行时分配记录：
-
V$AW_ALLOCATE_OP：只在AWR快照生成、聚合、清理过程中有数据，若某次OP_TYPE为SNAPSHOT后，ALLOCATED_BYTES长期不回落，且FREE_BYTES始终为0，就是AWR自身处理环节的泄漏线索 -
V$SGA_DYNAMIC_COMPONENTS：重点看CURRENT_SIZE与MIN_SIZE的差值。如果某个组件（如shared_pool）CURRENT_SIZE持续大于MIN_SIZE且不缩容，再配合V$SGASTAT中free memory持续萎缩，才值得怀疑 - 操作系统层：
ps -eo pid,vsz,rss,comm --sort=-rss | head -10查Oracle进程RSS是否随时间单向增长，比AWR更直接
用AWR做趋势对比时的关键操作点
如果你坚持用AWR做初步筛查，必须控制变量，否则对比毫无意义：
- 选相同工作负载时段：比如都选每天上午9:00–10:00，避开备份、ETL等干扰任务
- 固定快照间隔：用
DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT手动打快照，避免默认1小时间隔被跳过 - 对比具体字段而非笼统描述：不要只看“High Memory Usage”警告，要提取
PGA Aggr Used、SGA Target、Buffer Cache Size三列数值，算差值百分比 - 排除AMM/ASMM干扰：若
memory_target > 0，Oracle会动态重分配SGA/PGA，此时趋势波动属正常行为，V$MEMORY_TARGET_ADVICE比AWR更有参考价值
最容易被忽略的泄漏场景
真正的泄漏往往藏在非典型路径里：
- PL/SQL中用
DBMS_SQL.OPEN_CURSOR打开游标但没CLOSE_CURSOR，会导致shared pool里cursor heap持续膨胀，AWR里表现为library cache: mutex X等待上升+ shared pool free memory归零 - 外部过程（Extproc）调用C代码分配内存后崩溃退出，Oracle无法回收那块PGA，
V$PROCESS里对应进程的PGA_USED_MEM会锁死在高位 - AWR保留策略设为
NULL或过大（如365天），WRH$_ACTIVE_SESSION_HISTORY表不断写入但清理线程卡住，最终撑爆SYSAUX表空间——这不是内存泄漏，但症状高度相似
AWR趋势只是望远镜，真要动手解剖，得切开进程、查堆栈、盯分配链。别让“看起来像”耽误了定位黄金时间。