Understanding Buffer Pool Performance and Tuning in DB2 UDB v8.1

Understanding Buffer Pool 

Performance and Tuning in 

DB2 UDB v8.1 

Josh Steffan & Scott Olson 

Product Management 

DB2-Solutions

Agenda 

� Buffer pool overview 

� Buffer pool management 

� Collecting performance metrics 

� Buffer pool effectiveness criteria 

– Physical vs. logical IO 

– Asynchronous vs. synchronous IO 

– Page cleaner tuning 

� Tuning with Quest Central (live demo) 

� Open forum

Introduction 

� With so many tuning areas to focus 

on why should we pay special 

attention to the buffer pool? 

� DB2 uses the buffer pool to offset 

the performance disparity between 

CPU and disk, so they are vital for 

optimizing transaction throughput

You Are Here – DB2 Process Model 

Listener 

Client 

Application 

Coordinator 

Subagents 

Prefetchers 

Buffer Pool 

Logger 

External 

Storage 

Page 

Cleaners 

Log


Listener 

Client 

Application 


Subagents 

Prefetchers 


Logger 

External 

Storage 

Page 

Cleaners 

Log

Overview of DB2 Buffer Pools 

� A buffer pool is an area of memory into 

which database pages are read, modified, 

and held during processing 

– A hit occurs when a page that the database manager 

needs is found in the buffer pool 

– A miss occurs when a needed page can’t be found in 

the buffer pool 

� Pages in the buffer pool exist in one of 

three states: in use, dirty, or clean

Prefetching and Page Cleaning 

� Although buffer pools improve 

performance for pages in memory, the 

process of moving pages in and out of 

memory still requires a lot of IO 

� DB2 uses prefetch and page cleaner 

processes to reduce the time that agents 

have to wait for IO operations to 

complete

Prefetchers 

� Prefetchers (db2pfchr) ensure that agents doing 

scans never wait for disk IO 

� Agents send asynchronous read-ahead requests 

to a common prefetch queue 

� Prefetchers service the requests by bringing the 

requested pages into the buffer pool 

� Prefetching occurs two ways: 

– List prefetch, efficiently reads a set of nonconsecutive 

data pages 

– Sequential prefetch, reads consecutive pages

Page Cleaners 

� Page cleaners (db2pclnr) ensure that 

agents trying to bring a page into the 

buffer pool never need to flush a dirty page 

to disk to free up a slot 

� Configuration parameters 

– Number of page cleaners for a database 

(num_iocleaners) 

– Level (percentage) of changed pages at which the 

page cleaners will be started, if they are not 

currently active (chngpgs_thresh)


Listener 

Client 

Application 


Subagents 

Prefetchers 


Logger 

External 

Storage 

Page 

Cleaners 

Log

Non-Buffered IO 

� The buffer pool is not ideal for all types of IO 

� Large object data types such as LONG VARCHAR, 

BLOB and CLOB are retrieved directly from disk 

using non-buffered (direct) IO 

� Keeping large object pages out of the buffer pool 

helps DB2 maintain effective caching for small 

data types 

1 GB BLOB 1 GB BP Disk 

Without direct IO, 

large data types would 

force DB2 to flush all 

resident pages to disk 

– ruining the hit rate

Buffer Pool Management 

� The IBMDEFAULTBP is automatically created with 

each database with additional buffer pools added 

with the CREATE BUFFERPOOL statement 

� SYSCTRL or SYSADM privileges are required to 

work with buffer pools 

CREATE BUFFERPOOL bufferpool_name SIZE number of pages 

[IMMEDIATE | DEFERRED] 

[PAGESIZE integer [K]] 

[[NOT] EXTENDED STORAGE 

| NUMBLOCKPAGES number of pages [BLOCKSIZE number of pages]] 

[ALL DBPARTITIONNUMS 

| DATABASE PARTITION GROUP db_partition_group_name [,…]] 

[EXCEPT ON DBPARTITIONNUM[S] (db_partition_number1 [TO db_partition_number2] 

SIZE number of pages [,…])]

Buffer Pool Management 

� DB2 requires 100 bytes of memory for every 

buffer pool and extended storage page that is 

allocated to a database for use as a descriptor in 

the database heap (DBHEAP) 










Extended Storage 

� 32-bit DB2 can’t support creating buffer pools larger than 

4 gigabytes due to addressable storage limits 

� Extended storage allows DB2 to flush pages to memory 

rather than disk, so future access to the pages is much 

faster 

� Before extended storage can be used, the 

NUM_ESTORE_SEGS and ESTORE_SEG_SIZE database 

configuration parameters must be set 










Block-Based Buffer Pools 

� Applications that employ sequential prefetching can benefit 

from improved performance through the use of blockbased 

buffer pools, which allow blocks of contiguous pages 

to be moved into contiguous portions of memory 

� Keep in mind that block-based pages will be wasted if your 

application doesn’t perform sequential prefetching 










Hidden Buffer Pools 

� To improve availability, DB2 creates small (16 

page) buffer pools of each page size 4, 8, 16 and 

32 kilobytes at database activation 

� These buffer pools are hidden from the user and 

are only used when ordinary buffer pools cannot 

be allocated 

� If used, performance will be noticeably impacted 

and DB2 will write a warning message to the 

administration notification log

Related Objects 

� The table space create statement specifies a 

buffer pool to use, so it is the table space and 

not the table that determines in which buffer 

pool the pages will be cached 

� buffer pool and table space page sizes must 

match – valid values are 4, 8, 16, and 32 

kilobytes 

� Database partition group are also related to 

buffer pools, since a partition group can be 

specified in the CREATE BUFFERPOOL statement 

to control upon which partitions a given buffer 

poll is created

Buffer Pool Tuning Methodology 

� Collect the performance data 

– Snapshot monitoring 

– Event monitoring 

� Review the results (Know what to look for?) 

– Understand SQL workload 

– Evaluate performance (calculations) 

� Take action (examples) 

– Resize buffer pools 

– Define more page cleaners 

– Break out tables with “like” workloads 

� Start the process again

Collecting Performance Data 

Snapshot monitor 

“Point in time” representation of data 

Less overhead (~5%) 

Need to reissue over time 

Monitor Switches need to be turned 

on at the instance level to collect 

data 

“Real time” balance of application and 

database performance 

Event Monitor 

“Event” based representation of data 

More overhead (~10-20%) 

“Create” it once and it runs until it’s 

told to stop. 

“Create” takes care of everything 

“Historical” main focus on Application 

statistics

DB2 Snapshot Monitor 

� Seven Switches 

– Buffer Pool (dft_mon_bufpool) 

– Lock (dft_mon_lock) 

– Sort (dft_mon_sort) 

– Statement (dft_mon_stmt) 

– Unit of Work (dft_mon_uow) 

– Table (dft_mon_table) 

– Timestamp (dft_mon_timestamp)


� Turning switches on at the instance 

UPDATE DATABASE MANAGER CONFIGURATION USING 

dft_mon_bufpool ON 

dft_mon_lock ON 

dft_mon_sort ON 

dft_mon_stmt ON 

dft_mon_table ON 

dft_mon_uow ON 

IMMEDIATE 

� Turning switches on for session 

UPDATE MONITOR SWITCHES USING bufferpool ON


� Issuing a request 

– Instance level (requires “ATTACH”) 

• For all active databases 

GET SNAPSHOT FOR ALL BUFFERPOOLS 

• For a specific database 

GET SNAPSHOT FOR BUFFERPOOLS ON database_name 

• For a specific database partition 

GET SNAPSHOT FOR BUFFERPOOLS ON database_name 

AT DBPARTITIONNUM db_partition_number 

� BUFFERPOOL and DATABASE snapshot calls are 

essential for tuning buffer pools.

DB2 Snapshot Output 

� BUFFERPOOL Snapshot 

Bufferpool name = BASEBP1 

Database name = BASEBALL 

Database path = 

C:\DB2\NODE0000\SQL00005\ 

Input database alias = BASEBALL 

Buffer pool data logical reads = 300 

Buffer pool data physical reads = 3490 

Buffer pool data writes = 3050 

Buffer pool index logical reads = 67 

Buffer pool index physical reads = 34 

. 

. 

. 

Node number = 0 

Tablespaces using bufferpool = 4 

Alter bufferpool information: 

Pages left to remove = 0 

Current size = 1000 

Post-alter size = 1000

DB2 Snapshot Output 

� DATABASE Snapshot 

Database name = AUTO_PRD 

Database path = C:\DB2\NODE0000\SQL00009\ 

. 

. 

. 

Buffer pool data logical reads = 165079 

Buffer pool data physical reads = 36264 

Asynchronous pool data page reads = 10546 

Buffer pool data writes = 3991 

Asynchronous pool data page writes = 3873 

Buffer pool index logical reads = 4014 

Buffer pool index physical reads = 558 

Asynchronous pool index page reads = 332 

Buffer pool index writes = 26 

Asynchronous pool index page writes = 26 

Total buffer pool read time (ms) = 8329 

Total buffer pool write time (ms) = 121852 

Total elapsed asynchronous read time = 5353 

Total elapsed asynchronous write time = 121292 

Asynchronous read requests = 1681 

LSN Gap cleaner triggers = 24 

Dirty page steal cleaner triggers = 63 

Dirty page threshold cleaner triggers = 33 

Time waited for prefetch (ms) = 626

Evaluating Performance 

� Know your workload 

– Is the SQL workload predominantly… 

• Update, insert, delete focused 

–Example 

»OLTP 

• Select focused 

–Examples 

»Ad hoc 

» Data warehouse 

– Event monitoring can help if you are unsure


Evaluating logical IO vs. physical IO: 

– Minimize the number of times DB2 needs to access 

physical memory 

Approach: 

– Overall hit rate 

– Data hit rate 

– Index hit rate 

– Physical IO read rate

Logical vs. Physical IO 

� Overall Hit Rate 

– Includes ALL data and index reads by buffer pool 

⎡ 

⎤ 

⎢ 

⎥ 

( . . . . . . ) 

BuffePoolOHR 

⎢ bp datalogical 

reads+ 

bp indexlogical 

reads 

BufferpoolOHR 

= 

⎥* 

100 

⎢⎛bp. 

index. 

logical. 

reads+ 

bp. 


physical. 

reads+ 

⎞⎥ 

⎢⎜ 

⎟⎥ 

⎣⎝bp. 

data. 

logical. 

reads+ 

bp. 

data. 

physical. 

reads ⎠⎦ 

� Low values = more physical IO 

� High values = more logical IO 

� 85 – 90% is a good starting point


� Data Hit Rate 

– Includes ALL data reads by buffer pool 

Bufferpool 

DHR 

= 

⎛ 

⎜ 

⎝ 

bp. 

data. 

logical . reads 

bp. 

data. 

logical . reads + bp. 

data. 

physical . reads 



� 85 – 90% is a good starting point 

⎞ 

⎟* 

100 

⎠


� Index Hit Rate 

– Includes ALL index reads by buffer pool 

Bufferpool 

IHR 

= 

⎛ 

⎜ 

⎝ 

bp. 


logical . reads 

bp. 


logical . reads + bp. 


physical . reads 



� 85 – 90% is a good starting point 

⎞ 

⎟ * 100 

⎠


� Physical IO Read Rate 

– Total number of physical reads by buffer pool over 

time 

PhysicalIOReads 

= 

⎛ bufferpool. 

data. 

logical. 

reads + bufferpool. 

data. 

⎜ 

⎝ 

total. 

collection. 

time 

� Use the following: 

GET SNAPSHOT FOR TABLESPACES ON database_name 

� Evaluated by tablespace/buffer pool 

� Could indicate the need for… 

– Additional containers 

– Buffer pool breakout 

physical. 

reads 

⎞ 

⎟ 

⎠


Evaluating Prefetch Performance: 

– Asynchronous vs. synchronous 

Approach: 

– Evaluate prefetch ratio 

– Know the workload 

– Evaluate prefetcher configuration

Asynchronous vs. Synchronous 

� Prefetch Ratio 

– Evaluated by buffer pool 

PrefetchRatio 

= 

⎛ 

⎜ 

⎝ 

async.pool.data.reads 

bp.logical.reads 

� Lower values = more synchronous 

� Higher values = more asynchronous 

� Are there enough defined? 

+ 

+ 

async.pool.index.reads 

bp.index.logical.reads 

⎞ 

⎟* 

100 

⎠

Asynchronous vs. Synchronous 

� Block IO 

– If sequential prefetch is happening? 

• Enable buffer pools to utilize block IO 

ALTER BUFFERPOOL basebp2 NUMBLOCKPAGES 30; 

ALTER BUFFERPOOL basebp2 BLOCKSIZE 10; 

– NUMBLOCKPAGES should be a multiple of 

block size


Evaluating Page Cleaner Performance: 

– LSN Gap Triggers 

– Dirty Page Threshold Triggers 

– Dirty Page Steal Triggers 

Approach: 

– Evaluate each one against all others 

– Modify parameters influencing page cleaner activity 

– Do you have enough page cleaners defined?

LCR 

Page Cleaner Performance 

� Log Cleans Ratio 

⎛ 

⎞ 

⎜ 

⎟ 

⎜ 

lsn. 

gap. 

cleaner. 

triggers 

⎟ 

= ⎜ 

* 100 

⎛ dirt. 

page. 

steal. 

cleaner. 

triggers + lsn. 

gap. 

cleaner. 

triggers ⎞ 

⎟ 

⎜ 

⎟ 

⎜ 

⎜ 

⎟ 

. . . . 

⎟ 

⎝ ⎝ + dirty page threshold cleaners triggers ⎠ ⎠ 

� Has an affect on recovery times 

� Too small or too large could be detrimental to 

buffer pool performance 

� Affected by SOFTMAX DB CONFIG parameter

TCR 


� Threshold Cleans Ratio (dirty pages) 

⎛ 

⎞ 

⎜ 

⎟ 

⎜ dirty. 

page. 

threshold . cleaner. 

triggers ⎟ 

= ⎜ 

* 100 

⎛ dirt. 

page. 

steal. 

cleaner. 


gap. 

cleaner. 

triggers ⎞ 

⎟ 

⎜ 

⎟ 

⎜ 

⎜ 

⎟ 

. . . . 

⎟ 

⎝ ⎝ + dirty page threshold cleaner triggers ⎠ ⎠ 

� CHNGPGS_THRESH DB CONFIG parameter 

� The same 50% value has a different effect on 

small and large buffer pools 

� Finding a “happy” median is key

VCR 


� Victim Cleans Ratio (dirty pages) 

⎛ 

⎞ 

⎜ 

⎟ 

⎜ 

dirty. 

page. 

steal. 

cleaner. 

triggers 

⎟ 

= ⎜ 

* 100 

⎛ dirt. 

page. 

steal. 

cleaner. 


gap. 

cleaner. 

triggers ⎞ 

⎟ 

⎜ 

⎟ 

⎜ 

⎜ 

⎟ 

. . . . 

⎟ 

⎝ ⎝ + dirty page threshold cleaner triggers ⎠ ⎠ 

� If above 40%, typically means buffer pool needs 

to be larger 

� Could also mean SOFTMAX parameter is too high 

(not enough page turnover)

Conclusion 

� Focus on three main areas… 

– BP hit ratios (logical vs. physical) 

– Prefetcher tuning (asynchronous vs. synchronous) 

– Page cleaner tuning 

� Collect the performance data over time 

– Sampling methodology 

• Sample snapshots every 5-15 minutes over the course of the 

day or during a batch run 

� Review the results (Know what to look for?) 

– Decipher data and plug into equations 

– Know the workload 

– Chart performance over time 

� Take action 

– Various solutions depending on findings

Thank you

Understanding Buffer Pool Performance and Tuning in DB2 UDB v8.1

Create successful ePaper yourself

Delete template?

Save as template?