1. PGA的概念以及所包含的内存结构
作为一个复杂的oracle数据库系统来说,每时每刻都要处理不同的用户所提交的SQL语句,获取数
据并返回数据给用户。众所周知,解析SQL语句的工作是在oracle实例中的shared pool所完成的。那么对于每个session来说,其执行SQL语句时所传入的绑定变量放在哪里?而且,对于那些需要执行比较复杂SQL的session来说,比如需要进行排序(sort)或hash连接(hash-join)时,这时这些session所需要的内存空间又从哪里来?另外,还有与每个session相关的一些管理控制信息又放在哪里?对于诸如此类与每个session相关的一些内存的分配问题,oracle通过引入PGA这个内存组件来进行解决。
1.1 PGA的相关概念
PGA按照oracle官方文档解释,叫做程序全局区(Program Global Area),但也有些资料上说还可以理解为进程全局区(Process Global Area)。这两者没有本质的区别,它首先是一个内存区域,其次,该区域中包含了与某个特定服务器进程相关的数据和控制信息。每个进程都具有自己私有的PGA区,这也就意味着,这块区域只能被其所属的进程进入,而不能被其他进程访问,所以在PGA中不需要latch这样的内存结构来保护其中的信息。笼统的来说,PGA里包含了当前进程所使用的有关操作系统资源的信息(比如打开的文件句柄等)以及一些与当前进程相关的一些私有的状态信息。
每个PGA区都包含两部分:
固定PGA部分(Fixed PGA):这部分包含一些小的固定尺寸的变量,以及指向变化PGA部分的指针。
变化PGA部分(Variable PGA):这部分是按照堆(Heap)来进行组织的,所以这部分也叫做PGA堆。可以从X$KSMPP视图中看到有关PGA堆的分布信息。PGA堆中所包含的内存结构包括:
有关一些固定表的永久性内存。
如果session使用的是专用连接方式(dedicated server),则还含有用户全局区(UGA-User Global Area)子堆。如果session使用的是共享连接方式(shared server),则UGA位于SGA中。
调用全局区(CGA-Call Global Area)子堆。
1.2 UGA(用户全局区)的相关概念
UGA是包含与某个特定session相关信息的内存区域,比如session的登录信息以及session私有的SQL区域等。每个UGA也包含两个部分:
固定UGA部分(Fixed UGA):这部分包含一些小的固定尺寸的变量,以及指向变化UGA部分的指针。
变化UGA部分(Variable UGA):这部分也是按照堆来进行组织的,可以从X$KSMUP视图中看到有关UGA堆的分布情况。UGA堆的分布与OPEN_CURSORS、OPEN_LINKS等参数有关系。所谓的游标(cursor)就是放在这里的。UGA堆中所包含的内存结构包括:
私有SQL区域(Private SQL Area):这部分区域包含绑定变量信息以及运行时的内存结构等数据。每一个发出SQL语句的session都有自己的私有SQL区域。这部分区域又可分成两部分:
永久内存区域:这里存放了相同SQL语句多次执行时都需要的一些游标信息,比如绑定变量信息、数据类型转换信息等。这部分内存只有在游标被关闭时才会被释放。
运行时区域:这里存放了当SQL语句运行时所使用的一些信息。这部分区域的大小尺寸依赖于所要执行的SQL语句的类型(sort或hash-join等)和复杂度以及所要处理的数据行的行数以及行的大小。在处理SQL语句时的第一步就是要创建运行时区域,对于DML(INSERT、UPDATE、DELETE)语句来说,SQL语句执行完毕就释放该区域;而对于查询语句(SELECT)来说,则是在所有数据行都被获取并传递给用户以后被释放,或者该查询被取消以后也会被释放。
Session相关的信息。这部分信息包括:
正在使用的包(package)的状态信息。
使用alter session这样的命令所启用的跟踪信息、或者所修改的session级别的优化器参数(optimizer_mode)、排序参数(sort_area_size等)、修改的NLS参数等。
所打开的dblinks。
可使用的角色(roles)等。
从上面可以很明显的看出,我们最需要关注的就是私有SQL区域中的运行时区域了。实际上,从9i
以后,对这部分区域有了一个新的名称:SQL工作区域(SQL Work Area)。SQL工作区域的大小依赖于所要处理的SQL语句的复杂程度而定。如果SF1则,如果没有设置large pool,则UGA只能从shared pool里进行分配了。
如果session是通过专用服务器(dedicated server)方式连到数据库的,则UGA是从进程的PGA中进行分配的。
1.3 CGA(调用全局区)的相关概念
CGA也是一块内存区域,但它是动态的,随着调用(call)的开始而创建,在调用过程中一直存在,直到调用结束时被释放。它存放的是在调用过程中所需要的数据。
我们知道,调用主要包括解析(parse)调用、执行(executive)调用、获取(fetch)调用以及递归SQL调用和PL/SQL调用。从调用的种类可以看出,实际上在调用过程中所需要的数据,比如SQL AREA,PL/SQL AREA和SORT AREA基本都是放在UGA中的,因为这些数据在各个调用之间必须一直存在并可用。而在CGA中只存放了在调用过程中临时需要的数据,比如直接I/O缓存(Direct I/O Buffer)以及堆栈空间等数据结构。因此,没有CGA中的数据结构,调用是无法完成的。
注意,CGA不象UGA可以位于SGA中(以共享服务器模式连接),CGA一定是位于PGA中的。如果当前进程正在运行,则每个PGA中只有一个CGA。如果当前进程没有运行,则该进程的PGA中就没有CGA。
1.4 转储PGA
就象实例中的其他内存结构一样,oracle同样提供了可以将PGA转储到跟踪文件的方法。方法如下:
SQL> alter session set events 'immediate trace name heapdump level n';
其中的level n决定了将哪些内存堆转储到跟踪文件:
Level 1: PGA汇总信息
Level 2: SGA汇总信息
Level 4: UGA汇总信息
Level 8: 当前调用的汇总信息(CGA)
Level 16: 用户调用的汇总信息(CGA)
Level 32: Large pool的汇总信息(LGA)
Level 1025: PGA详细信息
Level 2050: SGA详细信息
Level 5000: UGA 详细信息
Level 8200: 当前调用的详细信息
Level 16400: 用户调用的详细信息
Level 32800: Large pool的详细信息
举例来说,我们转储PGA的汇总信息:
SQL> alter session set events 'immediate trace name heapdump level 1';
到user_dump_dest所定义的目录下,找到跟踪文件并打开,可以看到类似下面的信息:
******************************************************
HEAP DUMP heap name="pga heap" desc=001DB880
extent sz=0x213c alt=84 het=32767 rec=0 flg=2 opc=2
parent=00000000 owner=00000000 nex=00000000 xsz=0x213c
EXTENT 0 addr=03700034
Chunk 370003c sz= 8500 perm "perm " alo=7524
EXTENT 1 addr=0351BC8C
Chunk 351bc94 sz= 9156 freeable "Fixed Uga
"
EXTENT 2 addr=03519B3C
Chunk 3519b44 sz= 3764 perm "perm " alo=3764
Chunk 351a9f8 sz= 4196 free " "
Chunk 351ba5c sz= 540 freeable "kopolal dvoid "
……………
Chunk 45e988c sz= 4144 recreate "Alloc environm " latch=00000000
ds 45eade0 sz= 4144 ct= 1
Chunk 45ea8bc sz= 1484 freeable "kpuinit env han"
我们可以看到,其中的红色部分就是在PGA中所包含的固定UGA部分。同时,我们可以使用如下的命令将PGA的子堆也给转储出来,其中9.2以前使用:
SQL> alter session set events 'immediate trace name heapdump_addr level n';
9.2以后使用:
SQL> alter session set events 'immediate trace name heapdump_addr level 1, addr n';
其中的n表示子堆的地址。而子堆的地址可以在PGA的转储文件中找到。比如上面的例子中,我们可以看到这样的一行:
ds 45eade0 sz= 4144 ct= 1
这里的ds 45eade0就是某个子堆的地址,这是个十六进制的数值,于是我们先将其转换为十进制数值:
SQL> select to_number('45eade0','xxxxxxxx') from dual;
TO_NUMBER('45EADE0','XXXXXXXX')
-------------------------------
73313760
这里的73313760就是转储PGA子堆的命令中的n,所以我们可以执行(我的测试库为9.2.0.5):
SQL> ALTER SESSION SET EVENTS 'immediate trace name heapdump_addr level 1, addr 73313760';
2. PGA自动管理及深入研究
2.1 PGA自动管理概述
在9i之前,我们主要是通过设置sort_area_size、hash_area_size等参数值(通常都叫做*_area_size)来管理PGA的使用,不过严格说来,是对PGA中的UGA中的私有SQL区域进行管理,这块内存区域又有个名称叫做SQL工作区域。但是,这里有个问题,就是这些参数都是针对某个session而言的,也就是说设置的参数值对所有连进来的session都生效。在数据库实际运行过程中,总有些session需要的PGA多,而有些session需要的PGA少。如果都设置一个很小的*_area_size,则会使得某些SQL语句运行时由于需要将临时数据交换到磁盘而导致效率低下。而如果都设置一个很大的值,又有可能一方面浪费空间,另一方面,消耗过多内存可能导致操作系统其他组件所需要的内存短缺,而引起数据库整体性能下降。所以如何设置*_area_size的值一直都是DBA很头疼的一个问题。
而从9i起所引入的一个新的特性可以有效的解决这个问题,这个特性就是自动PGA管理。DBA可以根据数据库的负载情况估计所有session大概需要消耗的PGA的内存总和,然后把该值设置为初始化参数pga_aggregate_target的值即可。Oracle会按照每个session的需要为其分配PGA,同时会尽量维持整个PGA的内存总和不超过该参数所定义的值。这样的话,oracle就能尽量避免整个PGA的内存容量异常增长而影响整个数据库的性能。从而,就有效的解决了设置*_area_size所带来的问题。
不过遗憾的是,9i下的PGA