The DB2 Coupling Facility

DB2 uses the coupling facility to provide intermember communications. The primary function of the coupling facility is to ensure data availability while maintaining data integrity across systems. This requires the coupling facility to provide core services to the data sharing group such as locking and caching of data. To do so, the CF requires three structures to synchronize the activities of the data sharing group members :

• Lock structures are required to control global locking across the data sharing group members. Global locks are required because multiple members can access the same data. As such, each member needs to know the state of the data before it can be modified. The lock structure propagates locks to all members of the data sharing group.

• The list structure enables communication across the sysplex environment.

• Cache structures provide common buffering for the systems in the sysplex. When a data page is updated by an individual data sharing member, a copy of that page is written to one of the global buffer pools. If other members need to refresh their copy of the data page in question, the copy is obtained from the coupling facility's global buffer pool instead of from DASD. This requires the members to check the appropriate coupling facility global buffer pool first, to determine if the desired page needs to be read from DASD or not.

These structures ensure that data is synchronized between the members of the DB2 data sharing group.

Defining the Coupling Facility

A coupling facility is defined using Coupling Facility Resource Management (CFRM). CFRM is created by the IXCMIAPU utility. The CFRM is used to identify

• Each individual coupling facility

• Each structure within the individual coupling facilities

• Space allocated to these structures

• Ordered preferences and which coupling facility is used to store this ordered preference structure

• Unordered exclusion list, which defines the structures to keep separate from this structure

Global Lock Management

Because data sharing group members can access any object from any member in the group, a global locking mechanism is required. This is done by the lock structure defined in the coupling facility. The lock structure is charged with managing intermember locking. Without a global lock management process data integrity problems could occur when one member attempts to read (or change) data that is in the process of being changed by another member.

Data sharing groups utilize a global locking mechanism to preserve the integrity of the shared data. The global locking mechanism enables locks to be recognized between members.

For more details on the lock management process for data sharing environments, refer to Chapter 23, "Locking DB2 Data."

CF Lock Propagation Reduction

DB2 V8 reduces the propagation of locks to the coupling facility. This enhancement helps to reduce the cost of global contention processing and improve availability due to a reduction in retained locks in the event of a subsystem failure.

Global Inter-System Communication

The list structure component of the coupling facility contains status information used for inter-system communications. The list structure is also referred to as the Shared Communication Area, or SCA. The SCA maintains information about the state of databases, log files, and other details needed for DB2 recovery.

Global Data Buffering

Similar to the need for a global lock management technique, data sharing also requires global data buffering. Once again, this is so because a data sharing environment consists of multiple member DB2 subsystems. Each of those members has its own separate local buffer pools and each member can access and change data in any database on any subsystem within the data sharing group.

In a data sharing environment, data pages may be found in

• Local buffer pools

• Hiperpools

• Group buffer pools

• DASD (disk)

Updating and Reading Data

When data is modified, the changed data is stored in the buffer pool of the DB2 subsystem executing the transaction. The change is not immediately available to transactions that are executing in other members of the data sharing group. The coupling facility is used to provide all members of a data sharing group with a set of global buffer pools.

When modifications occur in a data sharing environment, DB2 must use force-at-commit processing. Force-at-commit writes pages changed by the transaction to the appropriate global buffer pools when a commit point is reached. Force-at-commit processing is used solely in a data sharing environment.

CAUTION

The changed page may be written prior to commit if local buffer pool write thresholds are reached.

NOTE

In a non-data sharing environment, DB2 does not write changed pages at a commit point. Instead, the buffer manager uses a deferred write algorithm, which moves the expensive buffer write operations outside of the transaction path length.

During the write to the global buffer pool, the coupling facility notifies DB2 members that currently have the page cached in their local buffer pool to invalidate it so that the next access will cause the page to be read from the global buffer pool (or disk).

The read transaction tests the validity of all pages it finds in its local buffer pool. If the page is still valid, the read transaction accesses the page from its local buffer pool. If the page is marked invalid (due to a previous update by another member), the read transaction will refresh the changed page from the global buffer pool (or disk).

Defining Data Sharing Buffer Pools

Data sharing members must use the same name for the global buffer pool as is used for the local buffer pool. For example, if BP5 is defined at the local subsystem level, BP5 must also be defined at the group buffer pool level. A group buffer pool must be defined for each associated local buffer pool. If a local buffer pool does not have a corresponding global buffer pool, resources utilizing the pool can only be used locally and cannot be shared.

For more information on group buffer pool specification and tuning, refer to Chapter 28, "Tuning DB2's Components."

Group Buffer Pool Duplexing

Prior to DB2 V6, if a group buffer pool failed, the only options for recovery were

• Recovering group buffer pools, whereby DB2 recovers data from its logs in case the group buffer pool structure is damaged, or if all members lose connectivity to the group buffer pool.

• Rebuilding group buffer pools, whereby DB2 copies pages from the group buffer pool to a new allocation of the structure in an alternative coupling facility (or to DASD, if DB2 cannot get enough storage in the alternate coupling facility).

However, as of DB2 V6 (or DB2 V5 with an APAR), when you have more than one coupling facility, you can duplex the group buffer pools. With group buffer pool duplexing, a secondary group buffer pool is waiting on standby in another coupling facility. In the event of a connection failure or if the primary group buffer pool fails, the secondary group buffer pool can take over (see Figure 19.2).

Figure 19.2. Group buffer pool duplexing.

With group buffer pool duplexing, you have two allocations of the same group buffer pool that use one logical connection. Each group buffer pool structure must be allocated in a different coupling facility.

With group buffer pool, duplexing pages that need to be written are written to the secondary group buffer pool structure asynchronously and to the primary group buffer pool structure synchronously. After all the required pages are written to the primary group buffer pool structure, DB2 double-checks on the writes to the secondary group buffer pool structure to ensure they have successfully completed. If any writes were not completed, DB2 forces them to completion.