和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