Introduction
~~~~~~~~~~~~
  This short article describes the fundamentals of the 'large pool'
  introduced in Oracle 8.0.

What is the Large Pool
~~~~~~~~~~~~~~~~~~~~~~
  The large pool is an area of the SGA similar to the shared pool, but with
  restrictions on its usage such that only certain types and sizes of memory 
  can be allocated in this pool.

  The memory for the large pool does NOT come out of the shared pool but 
  directly out of the SGA (system global area) thus adding to the amount of 
  shared memory Oracle needs at startup. 

  The size of the large pool is set by  
  and the minimum size chunk of memory which can be allocated is determined
  by . By default there is no large pool
  allocated - it must be explicitly configured.

  The three main uses of the large pool in Oracle 8 are:

	a. For the User Global Area (UGA) of sessions connected using MTS
	   (multi-threaded server)

	b. Buffering for sequential file IO (Eg: as used by server managed
	   recovery/RMAN when there are multiple IO slaves)

  Beginning in Oracle 8i, the large pool is also used for allocation of parallel
  execution buffers if PARALLEL_AUTOMATIC_TUNING is TRUE.

  NOTE: Starting with 10g px msg buffers are in shared pool if 
     sga_target = 0 and in the large pool if sga_target > 0 

     PARALLEL_AUTOMATIC_TUNING  is deprecated

  The large pool is protected by the 'shared pool' latch for memory allocation
  and management. Unlike the shared pool there is no LRU (least recently used)
  mechanism so chunks of memory are never aged out of the large pool - memory
  has to be explicitly allocated and freed by each session. If there
  is no free memory left when a request is made then an ORA-4031 will be
  signalled. 

  Space usage in the large pool can be seen using the .


MTS and the Large Pool
~~~~~~~~~~~~~~~~~~~~~~
  If there is a large pool configured MTS will ONLY try to use this pool
  for a sessions UGA. When a new session is started a small amount of memory 
  (known as the fixed UGA) is allocated in the shared pool and the rest of
  the session memory (UGA) is taken from the large pool.  If there is 
  insufficient space left in the large pool and ORA-4031 error will be 
  returned similar to this:

    ORA-04031: unable to allocate 636 bytes of shared memory 
		("large pool","EMPSCOTT","session heap","define var info")

  Memory is allocated from the large pool in chunks of at least 
  LARGE_POOL_MIN_ALLOC bytes in size to help avoid fragmentation. This
  may impact the amount of memory used by each MTS session when compared to
  memory usage with no large pool configured.

  If there is no large pool configured MTS uses the shared pool for the 
  entire UGA as was the case in Oracle7.

  NOTE: In Oracle Database 10g, Automatic Shared Memory Management (ASMM) 
        feature is introduced to automatically determine the size of Database 
        buffer cache (default pool), Shared pool,Large pool and Java pool by 
        setting the parameter SGA_TARGET. Refer to the following note available 
        in MetaLink for more information:

        Article-ID:         Note 257643.1
        Title:              Oracle Database 10g Automated SGA Memory Tuning

返回页首