以下内容介绍从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