Oracle内存结构全解析：SGA/PGA调优与ORA-04031排查实践-代码聚汇网

Oracle内存结构全解析：SGA/PGA调优与ORA-04031排查实践

happy最紧要·2026-09-02·阅读 22 GEO检测（免费）

Oracle内存结构SGAPGA

|难度：普通|阅读约 36 分钟

从很多年前第一次接触Oracle数据库开始，我就觉得内存结构是一个特别容易被忽视但又特别值得花时间搞懂的东西。面试的时候会考，文档里会写，可真到了生产环境出了性能问题或者半夜收到ORA-04031告警的时候，光知道"SGA是共享池，PGA是私有区"这种程度根本不够用。这篇内容我打算从内存结构的全貌讲起，把SGA和PGA里各个区域到底管什么事、参数怎么配、出了问题怎么排查，一次性说清楚。无论你是刚接触Oracle的开发、需要维护数据库的运维，还是已经在管生产库的DBA，这篇都适合你。

1. 内存结构全景：SGA与PGA的分工，以及为什么必须分家

1.1 一次故障现场：内存问题为什么难排查

先说一个我早些年遇到的案例。当时有一套业务系统每到月底跑批就会变慢，而且毫无规律，有时候上午十点卡住，有时候下午三点卡住。刚开始以为是SQL问题，抓了AWR报告以后发现DB Time全在一个“latch: shared pool”等待事件上，而在Top 5事件里居然还有大量的“free buffer waits”。那个时候我对Oracle内存结构的理解还停留在“SGA是共享内存池”这个层面，完全没意识到跑批SQL的并发解析、频繁的全表扫描、磁盘排序这些操作其实都在悄悄撬动内存的分配逻辑。

后来把sga_target调大了一点，pga_aggregate_target也调大了一点，问题暂时缓解，但过了一个月又复发。这个经历让我意识到一个很扎心的事实：调内存参数本质上是在跟Oracle的内存管理逻辑打交道，如果你不知道它内部怎么分配、怎么回收、怎么在组件之间腾挪空间，那参数调大了也只是一时掩盖问题，甚至可能把别的组件挤爆。

从那时候起，我开始系统性地把SGA和PGA的每一个子组件重新过了一遍。这个文章也算是给自己这些年踩过的坑做一个梳理。

1.2 SGA和PGA各自管什么：用一家餐厅来类比

Oracle实例的内存可以简单分成两大部分：SGA（System Global Area，系统全局区）和PGA（Program Global Area，程序全局区）。

我习惯用一个餐厅来打比方。SGA是这家餐厅的公共大堂和厨房，所有服务员（服务进程）共享这一块区域。点菜单放在大堂的台面上，谁都能看，谁都能取用；炒好的菜也先放在出菜口，等服务员来取。PGA则是每个服务员自己随身带的小本子和围裙口袋里的小工具，只属于自己，别人碰不到，自己负责的客人所涉及的私密信息都记在自己的小本子上。

通俗点讲：

SGA里放的是所有会话共享的数据：缓存的数据库块（Buffer Cache）、解析过的SQL和执行计划（Shared Pool里）、重做日志缓冲（Redo Log Buffer）、数据字典缓存等。
PGA里放的是单个会话私有的数据：排序操作（Sort）、哈希连接（Hash Join）、位图合并这些操作的中间结果、游标状态、PL/SQL变量等。

这个"分家"的设计是有讲究的。如果所有会话都共用一块内存且没有任何隔离，那么一个大型排序操作就能把内存占满，其他会话连共享的数据块缓存都没地方放。PGA的隔离机制保证了会话之间的私有操作互不干扰。SGA的共享机制则保证了高频访问的数据库块、SQL游标可以被所有会话复用，不需要每个会话都从磁盘读一遍。

1.3 实例与内存的生命周期：从启动到关闭

Oracle实例启动的时候，会先读取参数文件（spfile或pfile），然后根据参数值去操作系统申请内存映射，构建SGA和后台进程。实例关闭的时候，SGA被释放，所有缓存的数据块都会失效，下次启动需要重新从数据文件加载。

这里有一个概念需要分清：数据库（Database）和实例（Instance）是两回事。数据库指的是物理文件（数据文件、控制文件、重做日志文件），实例指的是内存结构加后台进程。实例可以挂载并打开数据库，实例关闭了，数据库数据文件还在。我们常说的"启动一个实例"，实际上就是在操作系统的内存地址空间里创造出一个SGA和一组后台进程。

内存结构的学习，我认为至少要抓住两个关键点：第一，SGA里各个组件是怎么协同工作的；第二，参数是怎么影响内存分配的。这两点搞清楚，后面看AWR、调优、排查问题，思路会清晰很多。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. SGA里谁最吃内存？Buffer Cache与Shared Pool的底层工作逻辑

2.1 Buffer Cache：数据不会直接进内存，而是通过DB Buffer

数据库里最频繁的操作一定是数据的读取和修改。如果每一次读数据都直接去磁盘，那IO会成为绝对瓶颈。Buffer Cache（数据库缓冲区缓存）就是用来缓存的：它把从数据文件读出来的数据块放到内存里，下次再要读同一块数据，直接命中内存，不需要再走磁盘。

每个数据块在Buffer Cache里都会有三种状态之一：

Pinned（固定）：正在被某个会话修改或读取，其他会话暂时不能动它。
Clean（干净）：内容与磁盘一致，可以被换出。
Dirty（脏）：已经被修改但还没有写回磁盘，需要由DBWR（数据库写进程）后台写回。

这里有一个特别常见的误区。很多人以为"Buffer Cache越大，数据读取就越快"。其实不完全对。Buffer Cache大到一定程度后，命中率提升的边际效应很低。更重要的是，Buffer Cache是SGA里的大户，它太大，会挤压Shared Pool以及其他组件的空间。所以生产环境调优，Buffer Cache的大小要根据实际数据访问的命中率和业务特性来定，而不是盲目往大了调。

监控Buffer Cache的使用情况，最常用的视图就是V$DB_CACHE_ADVICE，它可以模拟不同缓存大小下的物理读预测值，帮助你判断当前缓存是不是已经够用。

sql复制SELECT size_for_estimate AS cache_size_mb,
       estd_physical_read_factor,
       estd_physical_reads
FROM v$db_cache_advice
WHERE name = 'DEFAULT' AND block_size = 8192;

这个视图的输出很容易理解。estd_physical_read_factor接近1的时候，代表物理读的改善空间已经很小了，Buffer Cache再加大的收益非常有限。

2.2 Shared Pool：SQL解析与Library Cache，ORA-04031的根源

Shared Pool是SGA里另一个特别核心的区域，它主要由两部分组成：

Library Cache（库缓存）：存放SQL和PL/SQL的解析树、执行计划、游标定义等。
Data Dictionary Cache（数据字典缓存）：存放表、索引、列、用户、权限等元数据信息。

当一个SQL语句提交到Oracle，数据库会先计算哈希值，然后去Library Cache里找有没有相同的SQL文本。如果找到，就复用已有的执行计划，这叫软解析；如果找不到，就需要做硬解析，把SQL语法检查、语义检查、权限检查、生成执行计划，这个过程会消耗大量CPU和Shared Pool内存。

为什么ORA-04031这个错误这么经典？就是因为Shared Pool里的可用内存碎片化严重，拼凑不出一个足够大的连续内存块来存放新进来的对象。ORA-04031的本质不是"Shared Pool总量不够"，而是"可用碎片不够"，或者"连续空闲块不够"。所以很多人一遇到ORA-04031就把shared_pool_size调大，这只能缓解一时。如果SQL本身没有做绑定变量，导致海量硬解析不断往Library Cache里塞新游标，那Shared Pool再大也迟早被塞满。

判断Shared Pool是否健康，有三个最直接的指标：

硬解析比例：select * from v$sysstat where name like '%parse count%'，如果硬解析占比过高，优先考虑绑定变量。
Library Cache命中率：select * from v$librarycache，如果pins特别高但reloads很低，说明命中率不错。
共享池空闲内存：select * from v$sgastat where name = 'free memory' and pool = 'shared pool'，如果长期低于100MB，就要警惕了。

2.3 Redo Log Buffer与其他组件，以及如何查看各组件的实际使用

Redo Log Buffer是SGA里的一个环形缓冲区，专门用来记录数据库的修改信息，包括改变的数据块、回滚段的变化以及事务相关信息。LGWR后台进程会负责把Redo Log Buffer里的内容写到联机重做日志文件。

Redo Log Buffer的大小由参数log_buffer控制，它是一个以字节为单位的静态参数。很多系统默认值（通常是几MB到几十MB）在一般业务负载下是够用的。如果会话提交非常频繁，Redo Log Buffer里产生数据的速率超过了LGWR写盘的速率，就会出现log buffer space等待事件，这时才需要考虑把它调大。

SGA里还有一些相对冷门的组件，比如：

Large Pool：用于共享服务器模式下的UGA、并行查询的消息缓冲区、RMAN备份恢复操作的缓冲区。如果用了RMAN或者并行执行，建议显式配置large_pool_size，避免它去占用Shared Pool的空间。
Java Pool：用于JVM相关的Java对象存储，如果不用Java存储过程，一般不需要太大。
Streams Pool：用于Oracle GoldenGate和Streams相关的消息缓存。

想查看SGA各组件当前的实际分配情况，一个非常实用的视图是V$SGA_DYNAMIC_COMPONENTS，Oracle从9i开始支持SGA的动态调整后，组件的大小是可以进行动态变化的。

sql复制SELECT component, current_size, min_size, max_size, last_oper_type
FROM v$sga_dynamic_components;

看到这里你在实际运维中应该形成一个习惯：不要只看sga_target这个总参数，而是要经常钻到V$SGASTAT里看每个池和每个缓冲区的真实占用。

3. PGA：排序、哈希连接和会话私有区的内存账本

3.1 PGA里到底存了什么

如果说SGA是公共区域，那PGA就是私人包间。每一个会话都有一个自己的PGA，它不会和其他会话共享。PGA里主要包括：

SQL工作区（SQL Work Area）：排序（Sort）、哈希连接（Hash Join）、位图操作等复杂SQL操作的中间结果和临时区域。
会话内存（Session Memory）：会话级别的变量、PL/SQL包状态、游标状态等。
私有SQL区（Private SQL Area）：存放绑定变量信息、游标的运行时状态等。

PGA的管理是Oracle性能调优里非常容易犯迷糊的地方。很多人习惯把sga_target调得很大，结果留给PGA的内存就少了。但实际上，对于OLAP类报表系统、大量排序和哈希连接操作的系统，PGA不够用的后果往往比SGA不够用还要明显。因为排序如果放不进内存，Oracle就会把中间结果临时写到磁盘临时表空间，这个过程会产生大量的direct path read temp和磁盘排序等待。

3.2 PGA_AGGREGATE_TARGET与自动管理

从Oracle 9i开始引入了一个核心参数pga_aggregate_target，它规定了整个实例所有PGA内存合计的目标值，Oracle会根据这个目标值自动为每个会话的排序区、哈希区等分配内存。这个参数不是硬限制，而是软限制。Oracle会尽量让总PGA用量不超过它，但在某些大操作出现时也可以临时突破。

从Oracle 11g开始，如果启用了自动内存管理（AMM），你甚至可以只设置memory_target，让Oracle在SGA和PGA之间自动分配。但生产环境我一般不建议依赖AMM自动漂移，尤其是在大的OLTP系统上。

pga_aggregate_limit是后来版本加入的另一个参数，它是硬限制。当PGA实使用量超过这个值的时候，Oracle会通过终止超额会话、降级排序操作等方式来保护实例本身不因为内存耗尽而崩溃。

3.3 从v$pgastat看PGA是否够用

要判断PGA到底够不够，最直接的办法是看视图V$PGASTAT。

sql复制SELECT name, value, unit
FROM v$pgastat
WHERE name IN ('aggregate PGA target parameter',
               'aggregate PGA auto target',
               'global memory bound',
               'total PGA allocated',
               'over allocation count');

重点看两个指标：

over allocation count：如果这个值持续大于0，说明PGA发生了超额分配，也就是说实际PGA使用量超过了pga_aggregate_target，这是一个明显的报警信号。
global memory bound：它代表单个工作区可以使用的最大私有内存，如果这个值太小（例如只有几MB），那么大型排序和哈希操作就很容易落到磁盘。

还有V$SQL_WORKAREA_ACTIVE和V$SQL_WORKAREA_HISTOGRAM可以用来观察工作区的使用情况。如果发现大量排序操作都是使用磁盘临时空间（OPTIMAL执行次数为0或很小），那就说明PGA的配额给得太紧了。

我在实际调优中有一个习惯：先用AWR报告看Top 10等待事件里有没有temp disk sort或者direct path read temp与排序哈希相关的内容，再看PGA的命中情况。如果磁盘临时排序次数很多，我会优先把pga_aggregate_target调大，而不是急着去调SQL。

4. 内存参数调优的取舍：从SGA_TARGET到PGA_AGGREGATE_LIMIT，参数怎么定才不踩坑

4.1 手动管理、ASMM、AMM的演进逻辑

Oracle内存参数管理经历了三个阶段，理解这个演进逻辑对选型非常有帮助。

手动管理：在Oracle 9i以前，需要手动的为Buffer Cache、Shared Pool、Large Pool等分别设置大小，比如db_block_buffers、shared_pool_size等。这种方式静态、刻板，一旦分配不合理就白白浪费内存。
ASMM（Automatic Shared Memory Management）：从9i开始引入，在10g中成熟。通过设置sga_target，让Oracle自动在Buffer Cache、Shared Pool、Large Pool、Java Pool之间动态分配内存。这种方式的进步在于SGA内部可以动态调整。
AMM（Automatic Memory Management）：从11g开始引入。通过设置memory_target，让Oracle在SGA和PGA之间也自动调整，完全动态。它更灵活，但故障时也更难预测。

生产环境中我倾向于使用ASMM，即显式设置sga_target和pga_aggregate_target，而不使用memory_target。原因很简单：SGA的动态伸缩面向共享数据结构，PGA的动态伸缩面向会话私有操作，两者的峰值时间点往往不同。如果让Oracle自动在两者之间移动内存，可能在业务高峰时出现SGA和PGA"抢内存"的现象，而这种抢来抢去的代价是额外的内存复制和后台进程开销。

4.2 怎么根据AWR和视图判断内存是否不足

判断内存不足不能靠感觉，要综合几类指标：

Buffer Cache层面：

Buffer Cache命中率偏低（低于90%，且物理读突出）。
出现大量free buffer waits等待事件，说明Buffer Cache里找不到足够多的干净缓冲区来加载新块。
V$DB_CACHE_ADVICE显示在增大缓存时物理读明显下降。

Shared Pool层面：

硬解析次数占比高。
V$SHARED_POOL_ADVICE显示在增大Shared Pool时解析时间明显下降。
出现ORA-04031错误。

PGA层面：

V$PGASTAT的over allocation count大于0。
排序落在磁盘上的次数明显升高。
出现direct path read temp等待事件。

把这些数据综合起来，再结合操作系统层面的内存监控，才能判断瓶颈出在哪一环。

4.3 实际案例：一个系统频繁ORA-04031之后的调整过程

这里分享一个我在实际生产环境调理过的案例。系统为OLTP类型，版本是Oracle 11.2.0.4，内存16GB，参数配置是sga_target=8G，pga_aggregate_target=2G。某天开始频繁出现ORA-04031，报错信息指向shared pool。

我当时的排查过程是这样的：

查V$SGASTAT，发现shared pool的free memory只剩不到50MB，Library Cache里的SQL游标数量暴涨。
查V$SQL，发现存在大量文本相近但字面值不同的SQL语句，例如with不同时间范围查同一张表的查询。典型的未使用绑定变量。
检查应用层代码，确认确实有拼接SQL的情况。

这个问题的根源很清楚：SQL没有绑定变量，导致硬解析风暴，Shared Pool被海量游标塞满。就算我把shared_pool_size从1G调到3G，也只是让问题晚一点爆发，游标持续增加的话还是会继续堵。

最后我协调开发团队对业务SQL做了改造，把字面值替换成绑定变量，同时在数据库侧开启cursor_sharing=force作为过渡方案。改完以后，Shared Pool的free memory稳定在200MB以上，ORA-04031没有再出现。

这个案例的核心教训是：内存参数只是容器的容量，如果容器里的垃圾（无效游标、重复解析）不清理，容量再大也会被填满。解决内存问题一定要先看消耗方，而不是先加容量。

4.4 12c/19c里容易忽略的内存细节

Oracle 12c及之后的版本，内存结构在宏观上和之前一致，但有一些细节需要特别注意：

多租户架构（CDB/PDB）：每个PDB共享同一个SGA，但可以通过DB_CACHE_SIZE等参数在PDB级别做资源限制。在PDB级别执行的alter system set实际作用于该PDB的容器级别。
自动大页（Automatic Memory Management with HugePages）：从11g开始Oracle推荐使用HugePages来减少页表开销，到了19c，如果你启用了AMM，就不能直接使用标准HugePages，需要配置memory_target并配合操作系统的HugePages使用，否则会出现性能问题。
In-Memory Column Store（IM）：从12.1.0.1开始引入的列式内存区域，需要通过inmemory_size参数在SGA中划分出一部分内存，它默认不启用，启用时会占用SGA且不可与某些特性同时使用。

这些新特性在实际运维中会直接影响内存预算，建议在规划内存时阅读官方文档，不要把旧版本的参数习惯直接套到新版本上。

5. 内存故障排查的完整链路：从等待事件、视图到日志分析

5.1 常见内存相关等待事件，看到就别慌

内存故障在等待事件里往往有很典型的表现，我总结了几个最常见的：

等待事件	含义	常见原因
`latch: shared pool`	Shared Pool内部结构锁争用	硬解析过多、SQL游标频繁失效
`mutex: cursor`	游标相关互斥锁争用	SQL热游标、子游标过多
`free buffer waits`	Buffer Cache中找不到干净缓冲区	Buffer Cache过小、DBWR写回速度慢
`buffer busy waits`	数据块被多个会话并发争用	热块冲突、Buffer Cache配置不当
`log buffer space`	Redo Log Buffer满，LGWR来不及写盘	Redo日志文件IO慢、log_buffer过小
`direct path read temp`	排序/哈希操作直接读临时表空间	PGA内存不足，工作区落盘
`enq: TX - index contention`	索引争用导致的事务锁等待	索引单调递增，并发插入热点块

如果你在AWR报告或者EM里看到这些等待事件，先别急着改参数。等待事件只是表象，你要顺着它们去找根因。

5.2 ORA-04031和ORA-04030的定位思路

ORA-04031我们已经讲过，它是Shared Pool内存碎片化导致。定位步骤：

查V$SGASTAT确认shared pool free memory。
查V$SQL和V$SQLAREA看SQL数量、解析次数、版本数。
查V$SHARED_POOL_ADVICE看调大Shared Pool是否有效。
查看告警日志中报错的上下文，报错的SQL是谁。

ORA-04030则不同，它是进程PGA内存分配失败。这种错通常意味着操作系统无法分配更多内存，常见原因包括：PGA超过了pga_aggregate_limit、操作系统进程数或虚拟内存限制、32位进程地址空间限制等。定位思路是：

查看V$PGASTAT确认是否over allocation。
用ps -ef | grep oracle查看进程数量，确认是否有连接风暴。
查看系统级/var/log/messages或dmesg是否有内存不足（OOM Killer）的记录。
检查sga_target和pga_aggregate_target的配比是否超出物理内存。

5.3 用动态视图实时观察内存变化

排查内存问题还要掌握几个能"实时看内存变化"的视图，它们在高峰期非常有价值：

sql复制-- 查看SGA整体信息
SELECT * FROM v$sgainfo;

-- 查看SGA各组件动态调整情况
SELECT * FROM v$memory_dynamic_components WHERE current_size > 0;

-- 查看SGA空闲内存分布
SELECT pool, name, bytes/1024/1024 AS mb
FROM v$sgastat
WHERE name = 'free memory';

-- 查看PGA总体情况
SELECT * FROM v$pgastat;

-- 查看当前SQL工作区的使用情况
SELECT sid, work_area_size, expected_size, actual_mem_used, max_mem_used
FROM v$sql_workarea_active;

在Oracle 12c及以上版本，还可以通过V$SGA_CURRENT_RESIZE_OPS实时查看SGA动态调整的操作进行状态。如果发现SGA的动态调整操作非常频繁，说明当前参数设置与业务负载不匹配，需要重新评估。

5.4 一个完整的排查案例：从AWR到定位再到验证

最后给大家提供一个完整的排查思路，这个案例我遇到过不止一次，特别有代表性。

场景：一套关键业务系统在业务高峰期响应时间突然劣化，AWR报告显示Dashboard上"Top 10 Foreground Events"中direct path read temp排在第一位。

第一次排查：我看到这个等待事件后第一时间怀疑PGA不足，于是查看V$PGASTAT，发现over allocation count确实大于0，global memory bound只有几MB。于是我把pga_aggregate_target从2G调到了4G。

重启后：over allocation确实消失了，但业务响应时间并没有明显好转，direct path read temp依然很多。

第二次排查：我把注意力转向了SQL，查到具体SQL语句是一个大范围查询，对一张上亿行的表做全表扫描，并且有ORDER BY。Oracle需要对这个结果集排序，而排序的数据量大到即使PGA充足也无法完全放入内存。

优化SQL：添加了合适的索引、缩小了查询范围之后，临时排序的操作量大幅下降，direct path read temp消失，业务恢复正常。

这个案例给我最大的启发是：内存结构分析只是第一步，最终要回归业务与SQL本身。内存不足有两种，一种是"容器整体不足"，一种是"单个操作需求过大"。前者调整参数通常有效，后者即便内存给得再多也不够，必须从操作源头优化。

实际工作中，我养成了一个习惯：每次做内存调优前都先写一个"症状清单"，把等待事件、视图指标、错误日志、SQL运行状况都记录清楚，再动手改参数。改完之后再记录一份"效果清单"进行对比。这套方法论虽然看起来笨，但是能避免很多"调完参数发现还是没解决"的尴尬。

回到开头那个问题：Oracle内存结构为什么值得认真学？因为它不只是面试题，更是你诊断数据库性能问题的第一现场。把SGA和PGA各个角色的职责、参数的原理、视图的读法、等待事件的关联串起来，你会发现数据库的很多疑难杂症都有了清晰的解决路径。最后再分享一个小小的经验：对于Oracle内存调优，宁可花几天时间把业务和SQL摸清，也不要只花几分钟把一个参数调大。后者通常会把问题从内存层面转移到另一个你更陌生的层面。