PerformanceWiki [the blog]

David J. Kline, and Gabor Wieser from IBM describes, in very simple terms, how bufferpools in DB2 should be designed. In their article on developerWorks, they described the following:

The
most important reason to use more than one user table space is to
manage buffer utilization. A table space can only be associated with
one buffer pool, though one buffer pool can be used for more than one
table space.

The goal of buffer pool tuning is to help DB2
make the best possible use of the memory available for buffers. The
overall buffer size has a great effect on DB2 performance, since a
large number of pages can significantly reduce I/O, which is the most
time consuming operation. However, if the total buffer size is too
large, and there is not enough storage to allocate them, then a minimum
buffer pool for each page size will be allocated, and performance will
be sharply reduced. To calculate the maximum buffer size, all other
storage utilization must be considered by DB2 as well as the operating
system and any other applications. Once the total available size is
determined, this area can be divided into different buffer pools to
improve utilization. If there are table spaces with different page
sizes, then there must be at least one buffer pool per page size.

Having
more than one buffer pool can preserve data in the buffers. For
example, let’s suppose that a database has many very frequently used
small tables, which would normally be in the buffer in their entirety
and thus would be accessible very fast. Now let’s suppose that there is
a query which runs against a very large table, which uses the same
buffer pool and involves reading more pages than the total buffer size.
When this query runs, the pages from the small, very frequently used
tables will be lost, making it necessary to re-read them when they are
needed again.

If the small tables have their own buffer
pool, thereby making it necessary for them to have their own table
space, their pages cannot be overwritten by the large query. This will
likely lead to a better overall system performance, albeit at the price
of some small negative effect on the large query. Very often tuning is
a trade-off between different functions of a system to achieve an
overall performance gain. It is essential to prioritize functions and
bear total throughput and usage in mind, while making adjustments to
the performance of a system.

A new feature introduced with V8 and beyond is the ability to change buffer pool sizes without shutting down the
database. The ALTER BUFFERPOOL statement with the IMMEDIATE option will
take effect right away, except when there is not enough reserved space
in the database-shared memory to allocate new space. This feature can
be used to tune database performance according to periodical changes in
use, for example switching from daytime interactive use to nighttime
batch work.

.pw.