This chapter is from the book
This chapter is from the book
This chapter is from the book
Subsystem Pools
In the DBM1 address space are many objects critical to the operation of DB2. Here, we take a brief look at buffer pools and the RID, EDM, and Sort pools. For tuning information about the performance or use of these pools, refer to Chapter 17.
Buffer Pools
Buffer pools are database objects used to cache database data pages in memory. If an object's data page is placed in a buffer pool, physical input/output (I/O) access to disks will be avoided. Buffer pools can be assigned to cache only a particular table space's data, that is, within the table space definition.
Buffer pools are areas of virtual storage that temporarily store pages of table spaces or indexes. When a program accesses a row of a table, DB2 places the page containing that row in a buffer. When a program changes a row of a table, DB2 must eventually write the data in the buffer back to disk, normally at either a checkpoint or a write threshold. The write thresholds are either vertical—at the page set level—or horizontal—at the buffer pool level. Storage for buffer pools is backed by memory in the DBM1 address space. Prior to version 8, this was limited to 2GB and dataspaces and hiperpools were used to provide more storage. Version 8 has a large area of real addressable memory provided by 64-bit addressability. With 64-bit support DB2 can address up to 16 exabytes (less some operating system overhead). This allows buffer pools to mainly exist in real memory with up to a total of 1TB for all buffer pools in the susbystem.
Up to 80 virtual buffer pools are available. This allows for
-
Fifty 4K-page buffer pools (BP0–BP49)
-
Ten 32K-page buffer pools (BP32K–BP32K9)
-
Ten 8K-page buffer pools
-
Ten 16K-page buffer pools
Buffer pools take their space in the DBM1 address space. A single buffer pool can be up to 1TB, but the total of all buffer pools in the subsystem is also 1TB. As mentioned previously, up to 80 buffer pools can be defined. Creating a buffer pool is easily done via an –ALTER BUFFERPOOL command. The following example shows how to create a 3,000-page buffer pool with a sequential threshold of 50 percent:
-ALTER BUFFERPOOL (BP3) VPSIZE(3000) VPSEQT(50)
(Fifty percent of the buffer pool can be used for sequentially processed pages and 50 percent for randomly processed pages.) For more information on tuning these parameters, refer to Chapter 17.
Each buffer pool can have a different size and different parameter settings. These parameters control such activities as writing changed pages to disk. Changes to the buffer pool sizes and thresholds are also done via the –ALTER BUFFERPOOL command.
Environmental Descriptor Manager Pool
The EDM pool contains many items, including the following:
-
EDM DBD cache
-
DBDs (database descriptors)
-
-
EDM pool
-
SKCTs (skeleton cursor tables)
-
CTs (cursor tables, or copies of the SKCTs)
-
SKPTs (skeleton package tables)
-
PTs (package tables, or copies of the SKPTs)
-
Authorization cache block for each plan, except one with CACHESIZE set to 0
-
-
EDM statement cache
-
Skeletons of dynamic SQL for CACHE DYNAMIC SQL
-
If the pool is too small, you will see increased I/O activity in the following DB2 table spaces, which support the DB2 directory: DSNDB01.DBD01, DSNDB01.SPT01, and DSNDB01.SCT02.
The impact of having too little memory for the statement cache for dynamic SQL is a small hit ratio, causing extra CPU for the full prepares and I/O on the catalog. The main goal for the EDM pool is to limit the I/O against the directory and catalog. If the pool is too small, response times will increase because of the loading of the SKCTs, SKPTs, and DBDs and repreparing the dynamic SQL statements because they could not remain cached.
By correctly sizing the EDM pool, you can avoid unnecessary I/Os from accumulating for a transaction. A SKCT, SKPT, or DBD that has to be reloaded into the EDM pool is additional I/O. This situation can occur if the pool pages are stolen because the EDM pool is too small. Pages in the pool are maintained on an LRU (least recently used) queue, and the least recently used pages are stolen, if required. In version 8, the DBD cache and dynamic statement cache sizes are separately configurable. EDM pool structures are mainly located above the 2GB bar.
Row Identifier Pool
The RID pool is used for storing and sorting RIDs for such operations as
-
List prefetch
-
Multiple index access
-
Hybrid joins
-
Enforcing unique keys while updating multiple rows
The optimizer looks at the size of the RID pool for prefetch and RID use. The full use of the RID pool is possible for any single user at runtime. Runtime can result in a table space scan if not enough space is available in the RID. For example, if you want to retrieve 10,000 rows from a 100,000,000-row table and no RID pool is available, a scan of 100,000,000 rows would occur, at any time and without external notification. The optimizer assumes that physical I/O will be less with a large pool.
The size is set with an installation parameter (128 KB–10,000 MB). The RID pool is created at start-up time, but no space is allocated until RID storage is needed. It is then allocated above the 16MB line in 16KB blocks as needed, until the maximum size you specified on installation panel DSNTIPC is reached. Some of the RID pool, 25 percent, is located below the 2GB bar and the remainder is located above the 2GB bar.
Sort Pool
At startup, DB2 allocates a sort pool in the private area of the DBM1 address space. DB2 uses a special sorting technique, called a tournament sort. During the sorting processes, this algorithm commonly produces logical work files called runs, which are intermediate sets of ordered data. If the sort pool is large enough, the sort completes in that area. More often than not, the sort cannot complete in the sort pool, and the runs are moved into the DSNDB07 work files that are used to perform sorts. These runs are later merged to complete the sort. When DSNDB07 is used for holding the pages that make up the sort runs, you could experience performance degradation if the pages get externalized to the physical work files, as they will have to be read back in later in order to complete the sort.
The sort pool size is also defined by a DSNZPARM and is currently 240KB to 128MB, with a 2MB default.