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