How updates are made in a data sharing environment

There are several steps to the update process in a data sharing environment.

You might be interested to know what happens to a page of data as it goes through the update process. The most recent version of the data page is shaded in the illustrations. This scenario also assumes that the group buffer pool is used for caching only the changed data (the default behavior) and that it is duplexed for high availability. Duplexing is the ability to write data to two instances of a group buffer pool structure: a primary group buffer pool and a secondary group buffer pool.

Suppose, that as the following figure shows, an application issues an UPDATE statement from DB2A and that the data does not reside in the member's buffer pool or in the group buffer pool. In this case, DB2A must retrieve the data from disk and update the data in its own buffer pool. Simultaneously, DB2A gets the appropriate locks to prevent another member from updating the same data at the same time. After the application commits the update, DB2A releases the corresponding locks. The changed data page remains in DB2A's buffer pool. Because no other Db2 subsystem shares the table at this time, Db2 does not use data sharing processing for DB2A's update.

Begin figure description. Member DB2A reads data from disk, updates it, and puts the changed data in its own buffer pool. End figure description. — Figure 1. Data is read from disk and updated by an application that runs on DB2A

Next, suppose that another application, which runs on DB2B, needs to update that same data page. (See the following figure.) Db2 knows that inter-Db2 interest exists, so when DB2A commits the transaction, Db2 writes the changed data page to the primary group buffer pool. The write to the backup (secondary) group buffer pool is overlapped with the write to the primary group buffer pool. DB2B then retrieves the data page from the primary group buffer pool.

Begin figure description. Member DB2B retrieves the data from the primary group buffer pool. End figure description. — Figure 2. How DB2B updates the same data page. When DB2B references the page, it gets the most current version of the data from the primary group buffer pool.

After the application that runs on DB2B commits the update, DB2B moves a copy of the data page into the group buffer pool (both primary and secondary), and the data page is invalidated in DB2A's buffer pool. (See the following figure.) Cross-invalidation occurs from the primary group buffer pool.

Begin figure description. After member DB2B updates the data, it writes the changed data to the primary and secondary group buffer pools. End figure description. — Figure 3. The updated page is written to the group buffer pool. The data page is invalidated in DB2A's buffer pool.

Now, as the following figure shows, when DB2A needs to read the data, the data page in its own buffer pool is not valid. Therefore, it reads the latest copy from the primary group buffer pool.

Begin figure description. DB2A reads the data from the group buffer pool the next time that it needs the data, because the data in its own buffer pool is invalid. End figure description. — Figure 4. DB2A reads data from the group buffer pool

Unlike disk-sharing systems that use traditional disk I/O and message-passing techniques, the coupling facility offers these advantages:

The group buffer pool interactions are CPU-synchronous. CPU-synchronous interactions provide good performance by avoiding process-switching overhead and by maintaining good response times.
The cross-invalidation signals do not cause processor interrupts on the receiving systems; the hardware handles them. The signals avoid process-switching overhead and CPU cache disruptions that can occur if processor interrupts are needed to handle the incoming cross-invalidations.