|
Snapshot Level Database Table Space Application |
Logical Data Grouping dbase tablespace bp_info appl |
Monitor Switch Buffer Pool Buffer Pool Buffer Pool Buffer Pool |
|
Resettable |
Yes |
|
|
Event Type Database Table Space Connection |
Logical Data Grouping db_event tablespace_event conn_event |
|
|
Element Name Element Type |
pool_data_l_reads counter |
Description: Indicates the number of logical read requests for data pages that have gone through the buffer pool.
Usage: This count includes accesses to data that is:
In conjunction with "Buffer Pool Data Physical Reads", you can calculate the data page hit ratio for the buffer pool using the following formula:
1 - (buffer pool data physical reads / buffer pool data logical reads)
In conjunction with "Buffer Pool Data Physical Reads", "Buffer Pool Index Physical Reads", and "Buffer Pool Index Logical Reads", you can calculate the overall buffer pool hit ratio using the following formula:
1 - ((buffer pool data physical reads + buffer pool index physical reads)
/ (buffer pool data logical reads + buffer pool index logical 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. In such case, you would focus your attention on smaller, frequently accessed tables, and on the indices. Perhaps, assigning them to an individual buffer pools, for which you can aim for higher hit ratios.