[One Moss per day]-Fundamentals of the Large Pool the following describes the 'large Pool 'introduced from Oracle 8 '. What is Large Pool ")? A large pool is an area in SGA similar to a shared pool, but its usage is strictly limited. Only a few types and sizes of memory can be allocated in this pool. The memory of the large pool is not from the shared pool, but directly from the SGA. Therefore, you need to increase the shared memory capacity when the instance starts. The size of the large pool is determined by the LARGE_POOL_SIZE parameter. The minimum memory chunk that can be allocated is determined by the LARGE_POOL_MIN_ALLOC parameter. By default, there is no large pool, and the configuration must be displayed. Three main purposes of a large pool: a. UGA region used for session connection through MTS (multi-thread server. B. sequential file IO cache (for example, when multiple IO Slaves exist, it is provided to the server that manages recovery/RMAN ). From Oracle 8i, if the PARALLEL_AUTOMATIC_TUNING parameter is TRUE, the large pool can also be used to allocate concurrent execution cache. Note: Starting from 10 Gb, if sga_target = 0, px msg is cached in the shared pool. If sga_target> 0, px msg is cached in the large pool. Select * from V $ SGASTAT; pool name bytes ------------ ---------------------------- large pool PX msg pool 1076000 parameter PARALLEL_AUTOMATIC_TUNING parameter has been deprecated. The shared pool is responsible for protecting the memory allocation and management of the large pool. Unlike the shared pool, there is no LRU (least recently used) mechanism, so the memory chunk will never replace the large pool-that is, each session must be displayed to allocate and release the memory. If there is no free memory for processing the request, an error with the ORA-4031 will be reported. You can use the V $ SGASTAT view to view space in a large pool. If you do not configure a large pool for MTS and a large pool, MTS can only use this pool for the UGA of the session. When a new session is started, a small piece of memory in the shared pool will be allocated (also known as fixed UGA), and the remaining session memory (UGA) will come from the large pool. If the large pool does not have enough space, an ORA-4031 error will be reported: ORA-04031: unable to allocate 636 bytes of shared memory ("large pool", "EMPSCOTT", "session heap ", "define var info") the minimum chunk of memory allocated by the large pool is the number of bytes defined by the parameter LARGE_POOL_MIN_ALLOC to avoid fragmentation. When compared with memory usage that does not use a large pool configuration, this will affect the total memory usage of each MTS session. If no large pool is configured, MTS uses the shared pool as the entire UGA, and Oracle 7 does this. Note: Oracle 10 Gb introduces the ASSM (automatic shared memory management) feature. By setting the SGA_TARGET parameter, it automatically determines the database buffer cache (default pool) the size of the Shared pool, large pool, and Java pool. The following MOS documents contain more information: Article-ID: Note 257643.1 Title: Oracle Database 10g automatic SGA Memory Tuning