DB2 data sharing is how z/OS shops keep SQL running when one LPAR, one CEC, or one member dies. High availability is not automatic just because you ticked “data sharing” on the install panels. You need a Parallel Sysplex, at least two Coupling Facilities, correctly sized SCA, lock structure, and group buffer pools, plus rebuild or duplexing so a CF failure is not a group outage.
A data sharing group is up to 32 Db2 members that share one catalog and directory and the same user data on shared DASD. Applications attach with a group attach name so JCL and CICS do not care which member is alive. Underneath, z/OS Parallel Sysplex provides:
Without a sysplex you can still run one Db2. You cannot get member-level failover or GBP cache coherency. Data sharing HA is a sysplex design first, a Db2 design second.
IBM’s planning list for CF availability is: physical protection of the CF, protection of the structures, and network connectivity. A single CF is a single point of failure for the group. Multiple CFs let you allocate structures on a secondary CF if the primary is damaged, and let you duplex SCA, lock, and GBP structures.
Prefer failure isolation: the CF that holds SCA and LOCK1 should not sit on the same CEC as the Db2 members that allocate those structures (watch integrated CFs / ICFs). If isolation is impossible, duplex SCA and LOCK1 with system-managed duplexing. Db2 12 added asynchronous system-managed duplexing for the lock structure to cut the cost of synchronous lock requests.
| Structure | Allocator | Role |
|---|---|---|
| group_SCA | ssnmMSTR | Required — group cannot function without it |
| group_LOCK1 | ssnmIRLM | Required — global locks and retained locks |
| group_GBPn | ssnmDBM1 | One GBP per local BP that caches shared data |
The shared communications area stores member and BSDS names, database exception status for objects and members, and recovery information (data set names, indoubt XI transactions). It coordinates startup. If the SCA is lost and cannot be rebuilt, you are in group restart. Size it large enough that exception states (RO, copy pending, recovery pending, REORG, CHECK pending) fit; an undersized SCA is an availability incident waiting to happen.
LOCK1 holds the lock table (hash classes for shared/exclusive interest) and the modify lock list (record list entries — update-type locks that can be retained if a member or z/OS fails). Global locking is how two members do not update the same row blindly. False contention (hash collisions) is a sizing problem: Auto Alter can grow storage but may feed the modify lock list rather than the lock table — rebuilding LOCK1 is how you enlarge the lock table itself.
SCA and LOCK1 can often be rebuilt dynamically on an alternate CF, which is why duplexing them is “less important than GBPs” if they are failure-isolated. If rebuild cannot get enough storage from the CFRM SIZE, rebuild fails and members come down.
Each local buffer pool that caches shared data needs a matching group buffer pool in the CF. You define GBPs in the CFRM policy.
| GBP | Local BP | Typical contents |
|---|---|---|
| GBP0 | BP0 | Catalog, directory, and anything assigned to BP0 |
| GBP1 | BP1 | Page sets assigned to BP1 (often catalog indexes or 4 KB work) |
| GBP8K0 / 16K / 32K | Matching local BPs | Larger page sizes; same dependency rules |
GBP0 maps to each member’s BP0 and caches the catalog and directory (and anything else in BP0). GBP1 maps to BP1. You can place different GBPs in different CFs; a single simplex GBP lives in one CF unless duplexed.
When two or more members open the same table space, index space, or partition and at least one opens it for write, that page set has inter-Db2 read/write interest and becomes GBP-dependent. Changed pages are written to the GBP (unless GBPCACHE(NO) / GBPCACHE NONE). Directory entries track which members have a page cached and drive cross-invalidation so nobody reads a stale local copy.
Changed pages in a GBP may be the only up-to-date copy until castout writes them to DASD. If a simplex GBP fails, Db2 must recover those pages (log, rebuild). That can stall GBP-dependent work. Duplex the GBP so Db2 can switch to the secondary: changed pages are already there, then gradually rebuild directory entries and cross-invalidate. No application outage unless both primary and secondary are lost.
123-DIS GBPOOL(*) TYPE(GCONN) GDETAIL(*) -DIS GROUPBUFFERPOOL(GBP0) CONNLIST(YES) D XCF,STR,STRNAME=DSNDB0A_GBP0
Watch directory reclaims, XI due to directory reclaims, and write failures because of no storage — those three are the classic “GBP too small / ratio wrong” symptoms.
Rebuild is z/OS allocating a new structure instance and populating it. Simplex rebuild discards the old instance. Duplex rebuild keeps both synchronized.
CFRM preference lists and REBUILDPERCENT control when z/OS rebuilds after connectivity loss. Auto Alter can grow structures toward SIZE. You still need enough CF storage on the alternate CF for a rebuild to succeed.
Member failure: one Db2 or one z/OS image dies. Remaining members continue. Retained locks from LOCK1 protect uncommitted pages. Automation should -START DB2 (or LIGHT restart) that member so locks release. This is the normal HA path.
Group recovery (group restart): SCA and/or LOCK1 lost and not rebuilt. All members abort. Restarting members rebuild structures from logs. This is the path you design out of with two CFs, failure isolation, and duplexing. GBP loss is usually not group restart — it is GBP recovery — unless you also lose the required structures.
Imagine several kitchens (members) cooking from the same pantry (shared disks). The hallway whiteboard (SCA) lists who is working and what is broken. The lock box (LOCK1) stops two cooks from stirring the same pot. The shared fridge (GBP) holds the latest leftovers so nobody eats yesterday’s soup. If one kitchen burns down, the others keep cooking — but they will not touch pots the missing cook left half-finished until that cook comes back. If the hallway whiteboard and lock box both vanish and you have no spare hallway, every kitchen stops until you rebuild them from diaries. Two fridges in two buildings (duplexed GBPs) mean you can still serve dinner if one fridge dies.
1. Which CF structures must exist for a Db2 data sharing group to function?
2. Why are multiple coupling facilities required for high availability?
3. What kind of duplexing do group buffer pools use?
4. What does GBP-dependent mean?
5. What happens on member failure in a well-designed group?