Coupling facility structures

Db2 relies on areas of storage in the coupling facility called structures.

Three types of structures exist: lock, list, and cache. Each structure type has a unique function. The following figure shows a sample configuration of the coupling facility structures that are used by Db2.
Figure 1. Coupling facility structures that are used by Db2 . This is a sample configuration. The lock structure and list structure (SCA) do not need to be in the same coupling facility.
Begin figure description. One coupling facility structure contains a lock structure, a list structure, and two cache structures. The other contains three cache structures. End figure description.

Members of a data sharing group use the following coupling facility structures to communicate and move data among themselves.

Lock structure
The lock structure protects shared Db2 resources (such as table spaces and pages) and enables concurrent access to those resources.

The system lock manager (SLM), a component of the z/OS® cross-system extended services (XES), presents global lock information to the lock structure on behalf of each member's IRLM.

The lock structure consists of two parts: a coupling facility lock list table (called the modified resource list), and a coupling facility lock hash table (called the lock table). The modified resource list records locks that protect changed data, thereby protecting the data in case of failure. The lock table contains the lock status information and the owning members of those locks, and is used to provide global lock serialization.

List structure (SCA)
The list structure contains the Db2 shared communications area (SCA). Each member uses the SCA to pass control information to the rest of the members in the group. The SCA contains all database exception status conditions and other information that is necessary for recovery of the group.
Cache structures (Db2 group buffer pools)
The cache structures are used as group buffer pools (GBPs), caching shared data pages for the members. You have the following options for caching data of interest to more than one member of a group:
  • Cache all data (read-only and updated)
  • Cache only data that is updated
  • Cache only system control pages (specific to LOB table spaces)
  • Cache no data; use the group buffer pool only for cross-invalidation

One group buffer pool exists for all member buffer pools of the same name. For example, each member must have a buffer pool 0 (BP0) that contains the catalog and directory table spaces. A group buffer pool 0 (GBP0) must exist on a coupling facility for that data sharing group.

Similarly, if a member creates table space X and associates it with buffer pool 1 (BP1), X is associated with BP1 for every member because there is only one definition of X in the catalog for the entire group. To share the data in X, you must define the cache structure, group buffer pool 1 (GBP1). If you do not define the group buffer pool, a single member can update X or more than one member can read X, but there can be no inter-Db2 read/write activity for X.

Recommendation: For data that is private to each member, such as work files or user data that only one member reads, define that data to a buffer pool for non-shared page sets. For example, assume that you want to associate all non-shared page sets with buffer pool 6 (BP6). If you want only member DB2A to access a non-shared table space Y, then define Y (and any indexes) to BP6. Define BP6 with a size of 0 (zero) and then you do not need to define the coupling facility structure for group buffer pool 6. By moving private data to buffer pools that are separate from buffer pools used by shared data, you can more easily monitor, and provide for more predictable performance of, private data.

Cross-invalidation of group buffer pools

Group buffer pools use a cross-invalidation mechanism to maintain data consistency across the buffer pools of group members. Shared data pages are registered in a group buffer pool directory in each cache structure, thus enabling the coupling facility control program to cross-invalidate the copies of data pages that are held in individual member buffer pools. Cross-invalidation takes place when a member's own buffer pool does not contain the latest version of the data. In this case, the member must reread the pages from either the group buffer pool or disk, if that member needs to reference the pages again.

Asynchronous cross-invalidation of group buffer pools

Db2 can perform cross-invalidation asynchronously to the completion of coupling facility write requests. This capability requires that the following conditions are true:

  • The coupling facility control code (CFCC) level (CFLEVEL) is 23 or greater.

Asynchronous cross-invalidation can occur for deferred writes or force-at-commit writes, and if at least an internally defined number of pages of a page set are written concurrently to the group buffer pool. Asynchronous cross-invalidation does not occur if the data page size is 32KB.

With asynchronous cross-invalidation, transactions do not need to wait until the invalidation process has completed. Although data sharing groups whose members are far from each other can experience more substantial performance improvement with asynchronous cross-invalidation, data sharing groups whose members are close together can also benefit. The performance improvement can be seen in accounting class 2 elapsed times.