DB2 Version 4.1
Sysplex Data Sharing

The IBM Sysplex is a cluster of MVS/ESA systems running on System/390 mainframes. Key components of the Sysplex are the Sysplex Timer and the Sysplex Coupling Facility.

The Sysplex Timer provides a common time reference for all systems, giving consistent date/time stamping for transactions, logs, and messages across the entire sysplex. Such consistency is required for successful system operation and recovery.

The Sysplex Coupling Facility provides (1) cluster-wide data locking, at a low level of granularity, and (2) stable data caching for Sysplex-wide read/write data. Typically, redundant 9674 machines are used for the coupling facility.



The machines in the Sysplex cluster access shared data through ESCON (Enterprise System CONnection) directors; these are I/O switches that provide high-speed access to multiple I/O resources from multiple sources. (They are similar in function to DEC's Star Coupler, but much faster because they allow multiple, simultaneous data transfers.)

With Sysplex, it is possible to scale systems vastly beyond the limits of a single MVS machine. In the diagram shown on the previous page, all four machines could have full read/write access to a single IMS or DB2 database.

DB2 Version 4, which offers query IO and CPU parallelism, operates in the Sysplex environment. Unlike IMS, the Sysplex implementation of DB2 supports caching of data in the Sysplex Coupling Facility; such caching is of interest primarily for data that is shared across the Sysplex and has a significant degree of update activity.

To be able to share data, instances of the DBMS running on separate MVS systems must be defined to the coupling facility as members of a data sharing group. When data subject to sharing is read, it is registered with the coupling facility. The coupling facility keeps track of each member's interest in the data and notifies each member when, and if, data in the member's buffer pool has been invalidated by an update occurring in another member. This is done by setting a bit in the Hardware Systems Area (HSA) memory of the affected member.



It is thus possible for each member of the data sharing group to have a copy of the same data resident in its own buffer pool, and to continue to use such data indefinitely, as long as it is not updated by another member. Thus, for data that is seldom updated, use of the coupling facility is minimal. But updating is still permitted with full integrity, and from any one of the member systems.

As noted earlier, DB2 permits shared data to be cached in the coupling facility. Because it takes considerably longer to fetch data from the coupling facility than from a member's local buffer pool, this is appropriate only if the data is likely to be frequently updated by multiple members of the data sharing group. It should be noted here that logging of updates is done by the members of the data sharing group, not the coupling facility, and that recovery of a database subject to shared updating requires participation of all the member systems that have updated it.



©Copyright 1996 Chuck Anesi all rights reserved