Tuning group buffer pools
With Db2 data sharing, group buffer pools are a key component to ensuring that Db2 does not read down-level data in its member pools. Physical locks (P-locks) are also used in that process. Your understanding of these processes is helpful when tuning the data sharing group for best performance.
- Ensures that Db2 does not read down-level data that is cached in its member buffer pools (cache coherency).
- Enables, as much as possible, a quick refresh of a down-level page without having to go to disk.
With Db2 data sharing, a database page can reside:
- In a local buffer pool
- In a group buffer pool
- On disk
Database pages continue to be cached in each member's buffer pools before they can be referenced or updated. Each sharing member can control its own buffer pool configurations (the size and number of buffer pools). However, if inter-Db2 read/write interest exists in the data, the group buffer pool is also used for caching data (unless the group buffer pool is defined as GBPCACHE (NO) or the page set is defined with GBPCACHE NONE).
The group buffer pool contains information necessary for maintaining cache coherency. Pages of GBP-dependent page sets are registered in the group buffer pool. When a changed page is written to the group buffer pool, all members that have this page cached in their buffer pools are notified that the page has been invalidated (this notification does not cause a processing interruption on those systems). This is called cross-invalidation. When a member needs a page of data and finds it in its buffer pool, it tests to see if the buffer contents are still valid. If not, then the page must be refreshed, either from the group buffer pool or disk.