Group buffer pools in DB2 data sharing

GBP0 and GBP1

There is a one-to-one name mapping: local BPn ↔ CF structure GBPn. You define the structure in the CFRM policy as groupname_GBPn. Each member still has its own BP0 with its own VPSIZE; they all share one GBP0.

• GBP0 — maps to BP0. Caches the catalog and directory table spaces and indexes, plus any other objects assigned to buffer pool 0, when they are GBP-dependent. If GBP0 is missing or too small, catalog access across members is the first thing that hurts.
• GBP1 — maps to BP1. Whatever you put in BP1 (often 4 KB indexes or selected table spaces) uses GBP1 once inter-Db2 interest appears.
• GBP8K0, GBP16K0, GBP32K, … — same rule for other page sizes. Create a GBP for every local BP that will hold shared data.

A simplex GBP resides in one CF. Duplexed GBPs have primary and secondary in different CFs. You can spread different GBP names across CFs so one CF loss does not take every cache.

1
2
3
-ALTER GROUPBUFFERPOOL(GBP0) GBPCACHE(YES) RATIO(5)
-DIS GROUPBUFFERPOOL(GBP0) CONNLIST(YES)
-DIS GBPOOL(*) TYPE(GCONN) GDETAIL(*)

GBP caching

The GBP has two kinds of slots:

• Directory entries — track which members have a page in a local buffer (and pages in the GBP). They drive coherency and cross-invalidation.
• Data elements — actual cached pages (usually changed pages) so a member can refresh without going to DASD.

Default behavior caches updated data. You can cache all pages, none, or use a LOB-oriented option. GBPCACHE(NO) on the GBP still maintains XI but forces more disk I/O after invalidation. That can be a last-resort CF-storage trade-off, not a general performance feature.

Prefer hitting CLASST (more targeted castout) over slamming into GBPOOLT. Write failures because the GBP is full of changed pages mean castout is too slow or the GBP is too small. Directory reclaims mean RATIO or size is wrong: you need roughly one directory entry for every local buffer that might hold a page plus one per GBP data page.

GBP-dependent

A table space, index space, or partition is GBP-dependent when there is inter-Db2 read/write interest: more than one member has it open, and at least one has it open for write. Then:

• Changed pages are written to the GBP (unless caching is disabled)
• Pages are registered in the GBP directory
• Physical locks (P-locks) on the page set help track that interest

If only one member has the page set open, it can stay non-GBP-dependent and behave much like a non-data-sharing buffer pool — until a second member shows up. Interest is dynamic: DB2A might update alone; when DB2B needs the same page, DB2A writes the dirty page to the (duplexed) GBP and DB2B reads it from the primary GBP.

Objects that never have inter-Db2 interest still need a GBP defined if they use that BP name, but they will not spend CF cache until interest appears. Catalog and directory in BP0/GBP0 are the structures that become GBP-dependent as soon as two members are active and touching the catalog — which is immediately in a real group.

Cross-invalidation

Cache coherency is the whole point. IBM’s update walk-through:

1. DB2A updates a page in its local BP. After commit, the page can remain in DB2A’s pool.
2. DB2B needs the same page. Inter-Db2 interest is detected. DB2A writes the changed page to the primary (and secondary, if duplexed) GBP.
3. DB2B reads the page from the primary GBP, updates it, and at commit writes it back to both GBPs.
4. The GBP cross-invalidates the copy still sitting in DB2A’s local buffer. That notification does not interrupt DB2A’s CPU; it sets a vector bit.
5. When DB2A reads the page again, it tests the local buffer, sees it is invalid, and refreshes from the GBP (or from disk if the page was not cached as a data element).

Later, the castout owner writes the page from the GBP to DASD so restart and GBP failure have a disk copy. Until castout, the GBP may hold the only current version — which is why duplexing GBPs is an availability requirement, not a luxury.

Cross-invalidation also happens when a directory entry is reclaimed. Those XIs are “false” from a business point of view: nobody updated the page; the GBP just ran out of directory slots. Tune RATIO before you blame the application.

Duplexing and recovery

User-managed duplexing: Db2 writes changed pages to both GBP instances. If you lose connectivity to the primary, Db2 can use the secondary without a log-based rebuild of those changed pages. Directory entries are rebuilt more gradually. If you lose both copies, you are in GBP recovery: reconstruct from DASD plus logs for pages not yet cast out. AUTOMATIC RECOVERY on DISPLAY GROUPBUFFERPOOL shows whether Db2 will attempt automatic GBP recovery.

1
2
D XCF,STR,STRNAME=DSNDB0A_GBP0
-DIS GROUPBUFFERPOOL(GBP0) GDETAIL(INTERVAL)

DISPLAY output includes class castout threshold, GBP castout threshold, checkpoint interval, recovery status, CFRM policy duplex indicator, and current duplexing mode (DUPLEX versus SIMPLEX). Use it.

Explain It Like I'm Five

Each Db2 member has a lunchbox (local buffer pool). When two kids share the same sandwich (a data page), they also use a fridge in the hallway (the GBP). If one kid adds mustard and puts the sandwich in the fridge, the other kid’s lunchbox copy gets a sticker that says “stale” (cross-invalidation). That kid then takes the mustard version from the fridge instead of eating the old one. GBP0 is the fridge for the school office files (catalog). GBP1 is another fridge for a different shelf of lunches. If the hallway fridge is the only place the mustard sandwich exists until someone writes it back to the pantry (castout), you want two fridges in two hallways (duplexing).

Exercises

1. Map BP0, BP1, and BP8K0 to GBP names and name one object class you would expect in GBP0.
2. Describe the moment a page set becomes GBP-dependent.
3. Why is XI from directory reclaim a sizing problem rather than an application bug?
4. Choose CLASST and GBPOOLT for a write-heavy GBP and explain the direction you would move them if write failures appear.
5. Read a DISPLAY GROUPBUFFERPOOL listing and identify duplexing mode and RATIO.