DB2 Version 9.7 for Linux, UNIX, and Windows

pool_data_l_reads - Buffer pool data logical reads monitor element

The number of data pages which have been requested from the buffer pool (logical) for regular and large table spaces.

Table 2. Snapshot Monitoring Information
Snapshot Level Logical Data Grouping Monitor Switch
Database dbase Buffer Pool
Table Space tablespace Buffer Pool
Buffer Pool bufferpool Buffer Pool
Application appl Buffer Pool
Application stmt Buffer Pool
Dynamic SQL dynsql Buffer Pool, Statement
For snapshot monitoring, this counter can be reset.
Table 3. Event Monitoring Information
Event Type Logical Data Grouping Monitor Switch
Activities event_activity (reported in the details_xml document) ACTIVITY METRICS BASE
Activities event_activitymetrics ACTIVITY METRICS BASE
Statistics event_scstats (reported in the metrics document) REQUEST METRICS BASE
Statistics event_wlstats (reported in the metrics document) REQUEST METRICS BASE
Unit of work Reported in the system_metrics document. REQUEST METRICS BASE
Database event_db -
Tablespaces event_tablespace -
Connection event_conn -
Statement event_stmt -
Activities event_activity Buffer Pool, Statement
Package cache Reported in the activity_metrics document. ACTIVITY METRICS BASE
Statistics event_scmetrics* REQUEST METRICS BASE
Statistics event_wlmetrics* REQUEST METRICS BASE
* When returned as part of this logical data group, this element reflects the change in value of this metric since the last statistics collection or database activation, whichever was more recent.

Usage

This count includes accesses to data that is:
  • Already in the buffer pool when the database manager needs to process the page.
  • Read into the buffer pool before the database manager can process the page.
Use the pool_data_l_reads and pool_data_p_reads monitor elements to calculate the overall data page hit ratio for the buffer the following formula:
 
1 - (pool_data_p_reads / pool_data_l_reads)

Increasing buffer pool size will generally improve the hit ratio, but you will reach a point of diminishing return. Ideally, if you could allocate a buffer pool large enough to store your entire database, then once the system is up and running you would get a hit ratio of 100%. However, this is unrealistic in most cases. The significance of the hit ratio really depends on the size of your data, and the way it is accessed. A very large database where data is accessed evenly would have a poor hit ratio. There is little you can do with very large tables.

To improve hit ratios for smaller, frequently accessed tables and indexes, assign them to individual buffer pools.