【每日一摩斯】-Fundamentals of the Large Pool
【每日一摩斯】-Fundamentals of the Large Pool
以下内容介绍从Oracle 8引入的‘Large Pool’。
什么是Large Pool(翻译过来叫“大池”)?
大池是SGA中一块类似于shared pool的区域,但是它的使用又有严格的限制,仅有几种类型和大小的内存能够在这个池中分配。
大池的内存不是来自于shared pool,而是直接来自于SGA,因此需要在实例启动时增加共享内存的容量。
大池的大小由LARGE_POOL_SIZE参数决定,可以分配的最小内存chunk由LARGE_POOL_MIN_ALLOC参数决定。默认没有大池,必须显示配置。
大池的三种主要用途:
a. 用于通过MTS(多线程服务器)方式连接的session的UGA区域。
b. sequential file IO的缓存(例如:当有多个IO Slaves时,提供给管理recovery/RMAN的server)。
从Oracle 8i开始,如果PARALLEL_AUTOMATIC_TUNING参数是TRUE,大池也可以用于并发执行缓存的分配。
注意:从10g开始,如果sga_target=0,则px msg缓存存于shared pool中,如果sga_target>0,则px msg缓存存于large pool中。
select * from V$SGASTAT;
POOL NAME BYTES
------------ -------------------------- ----------
large pool PX msg pool 1076000
参数PARALLEL_AUTOMATIC_TUNING参数已经被deprecated。
shared pool负责保护large pool的内存分配和管理。和shared pool不同,这里没有LRU(最近最少使用)机制,所以内存chunk从不会置换出大池-也就是需要每个session必须显示分配和释放内存。如果没有free内存用于处理请求,那么就会报ORA-4031的错误。
大池中空间的使用可以通过V$SGASTAT视图查看。
MTS和大池
如果没有配置大池,MTS将仅能用这个池给session的UGA。当启动新的session时,shared pool中的一小块内存将会被分配(也称作fixed UGA),其余的session内存(UGA)将来自于大池。如果大池没有足够的空间,ORA-4031的错误会被报出:
ORA-04031: unable to allocate 636 bytes of shared memory
("large pool","EMPSCOTT","session heap","define var info")
大池分配的内存chunk最小是参数LARGE_POOL_MIN_ALLOC定义的字节数,以避免碎片化。当与不使用大池配置的内存使用比较,这将会影响每个MTS的session使用的内存总量。
如果没有配置大池,MTS会使用shared pool作为整个UGA,Oracle 7就是这样做的。
注意:Oracle 10g,引入了ASSM(自动共享内存管理)的特性,通过设置SGA_TARGET参数,它会自动决定数据库buffer cache(默认池)、Shared pool、大池和Java pool的大小,如下MOS中的文档包含更多的信息:
Article-ID: Note 257643.1
Title: Oracle Database 10g Automated SGA Memory Tuning