和sga_target不同，pga_aggregate_target并不能限制PGA的大小。 另一个差别是，SGA是数据库启动时按照sga_max_size预先分配的，而PGA则是“按需分配”的。

      以下详细解释下，为什么pga_aggregate_target并不能限制PGA的大小。一般的文档会把PGA分为stack space和UGA两个部分，但这种提法太笼统，不利于我们理解这个问题。我们把它分为work area和work area之外的部分。

      所谓work area，就是session要执行SQL，需要在数据库内部分配的，为了存放中间结果的内存。 比如sort area，为了排序用的内存，比如hash area，为了hash join用的内存，这一部分直接和SQL执行相关，影响SQL执行的效率，比如更大hash area会让hash join更快。pga_aggregate_target实际上只限制work area的大小。当work area达到pga_aggregate_target的限制，则会产生4030错误。隐含参数_pga_max_size只是限制单个进程使用的work area大小，也是在pga_aggregate_target的限制之内的更小限制。而work area之外的内存，不被pga_aggregate_target和_pga_max_size所限制。所以你经常会看到PGA的大小超过了pga_aggregate_target。这通常是因为PL/SQL中的变量和数组中装入了巨大的数据造成的。通常的例子是bulk collect，imp/exp，sql loader等工具也会产生类似的问题。

      我下面给出一个具体的示例：
alter system set "_pga_max_size"=10m scope=both;
alter system set pga_aggregate_target=100m scope=both;
SQL> shutdown immediate
startup
SQL> select ksppinm as "hidden parameter", ksppstvl as "value" from x$ksppi join x$ksppcv  using (indx) where ksppinm like '%_pga_max_size%' order by ksppinm;
hidden parameter
--------------------------------------------------------------------------------
value
--------------------------------------------------------------------------------
_pga_max_size
10485760