In certain deployments, the buffer pool is a bottleneck that negatively impacts overall database performance due to low buffer hit ratios. The traditional solution to low buffer hit ratios is to increase the size of the buffer pool (-B), but this is not always possible or beneficial. The Alternate Buffer Pool gives the database administrator the ability to modify buffer pool behavior by designating objects or areas to consume buffers from the Alternate Buffer Pool, rather than from the primary buffer pool. The size of the Alternate Buffer Pool is specified with the startup parameter -B2. Both the Alternate Buffer Pool and the primary buffer pool consume shared memory, and the sum total of both buffer pools is limited by the established shared maximums.

The management of buffers in the Alternate Buffer Pool is separate from the primary buffer pool. As buffers in the Alternate pool are initially consumed, a First In-First Out (FIFO) queue of the buffers is maintained. When all the buffer are consumed, a Least Recently Used (LRU) replacement algorithm is employed to select buffers for eviction. The first buffer evicted is the head of the FIFO queue. However, the goal is to size the Alternate Buffer Pool such that there are always free buffers and the LRU replacement is not necessary. Monitoring of the Alternate Buffer Pool with PROMON indicates if the LRU replacement is activated. If possible, the database administrator should increase the size of the Alternate Buffer Pool with PROUTIL INCREASETO, or the database administrator should consider removing objects from the Alternate Buffer Pool to avoid utilizing LRU replacement. If the size of the Alternate Buffer Pool is increased, the LRU replacement algorithm is once again deactivated.

If you change buffer pool assignments for objects at runtime, existing buffers remain in the buffer pool where they were originally allocated.

Private read-only buffers (-Bp) are always obtained from the primary buffer pool regardless of the buffer pool designation of the object.

Database control and recovery areas cannot be assigned to the Alternate Buffer Pool.

If you do not specify a size for the Alternate Buffer Pool at startup, all objects and areas consume buffers from the primary buffer pool.

Specifying the best objects for the Alternate Buffer Pool is application-specific. Tables considered "hot" (very active) are good candidates, as are their related indexes, provided that the alternate buffer pool is sized to avoid requiring the use of the LRU replacement algorithm. Tables and indexes that are governed by an encryption policy are also considered good candidates because the cost of encrypting and decrypting blocks as they are written and read from disk can be high.