Large Pool- Memory Structures

The large pool is not so named because it is a “large” structure (although it may very well be large in size). It is so named because it is used for allocations of large pieces of memory that are bigger than the shared pool is designed to handle.

The large pool is a recycle-style memory space, whereas the shared pool is more like the keep buffer pool—if people appear to be using something frequently, then you keep it cached.

Memory allocated in the large pool is managed in a heap, much in the way C manages memory via malloc() and free(). As soon as you “free” a chunk of memory, it can be used by other processes. In the shared pool, there really was no concept of freeing a chunk of memory.

You would allocate memory, use it, and then stop using it. After a while, if that memory needed to be reused, Oracle would age out your chunk of memory. The problem with using only a shared pool is that one size doesn’t always fit all.

The large pool is used specifically by

•\ Shared server connections, to allocate the UGA region in the SGA
•\ Parallel execution of statements, to allow for the allocation of interprocess message buffers, which are used to coordinate the parallel query servers
•\ Backup for RMAN disk I/O buffers in some cases

As you can see, none of these memory allocations should be managed in an LRU buffer pool designed to manage small chunks of memory.

With shared server connection memory, for example, once a session logs out, this memory is never going to be reused, so it should be immediately returned to the pool.

Also, shared server UGA memory allocation tends to be “large.” Putting shared server memory into the shared pool causes it to fragment into odd-sized pieces, and, furthermore, you will find that large pieces of memory that will never be reused will age out memory that could be reused. This forces the database to do more work to rebuild that memory structure later.

The same is true for parallel query message buffers, since they are not LRU manageable. They are allocated and can’t be freed until they are done being used.

Once they have delivered their message, they are no longer needed and should be released immediately. With backup buffers, this applies to an even greater extent—they are large, and once Oracle is done using them, they should just “disappear.”

The large pool is not mandatory when using shared server connections, but it is highly recommended. If you don’t have a large pool and use a shared server connection,

the allocations come out of the shared pool. This will definitely lead to degraded performance over some period of time and should be avoided.

If SGA_TARGET is set, but no value for the LARGE_POOL_SIZE, then the default is zero (meaning it is internally determined by the Oracle database). If LARGE_POOL_SIZE is set, then it is used as a minimum value for the memory pool.

Leave a Reply

Your email address will not be published. Required fields are marked *