How Db2 writes to the group buffer pool

With data sharing, Db2 still performs deferred writes for Db2 table spaces, indexes or partitions. However, when an update is to a page set that has inter-Db2 read/write interest, Db2 forces the updated pages to the group buffer pool before or when the transaction commits.

Updated pages can be written to the group buffer pool before the updating transaction is committed when:
  • One of the deferred write thresholds is reached.
  • The buffer pool lacks reassignable buffers because writes to the group buffer pool cannot keep up with update activity in the buffer pool. The shortage of buffers can occur when the deferred write thresholds are too high, or if the application is not committing frequently enough—in a data sharing environment, the commits make buffers reassignable.
  • An updated page has stayed in the buffer pool for a long period of time since it was last referenced or updated (such as with a long-running transaction that does not issue frequent commits). In this case, a system checkpoint can free space in the buffer pool before the commit.
  • The same page is required for update by another system because no conflict on transaction locking exists (such as page sets that are using row locking, index pages, space map pages, and so on). This write is part of the page P-lock negotiation process.

When a page of data is written to the group buffer pool, all copies of that page cached in other members' buffer pools are invalidated. This means that the next time that one of those members needs that page, the page must be refreshed from the group buffer pool (or disk).

Before an updated page is written to the group buffer pool or to disk, Db2 also ensures that the last update log record for that page is externalized to the active log. This ensures that updates can be backed out when necessary.

When committing an updating transaction, Db2 synchronously writes to the group buffer pool pages that were updated but not yet written to the group buffer pool. If a group buffer pool is required and unavailable(because of a channel or hardware failure) at the time the transaction commits, Db2 places all the transaction's updated pages on the logical page list (LPL) associated with each page set. After the problem is fixed, Db2 attempts automatic LPL recovery, but you can issue a START DATABASE command with the SPACENAM option to manually recover the pages on the logical page list.
Note: When a table space or partition is placed in the LPL, at either restart time or during rollback processing, because undo processing is needed for a NOT LOGGED table space, automatic LPL recovery is not initiated and a START DATABASE command identifying this table space will have no effect on its LPL status.

Writing to a GBPCACHE(NO) group buffer pool

For GBP-dependent page sets, no data is written to a group buffer pool for the following instances:
  • The group buffer pool is defined as GBPCACHE(NO)
  • The page set is defined as GBPCACHE NONE
  • The changed pages are non-system pages of a page set defined with GBPCACHE SYSTEM

In these cases, Db2 writes changed pages for the transaction directly to disk at or before COMMIT. Db2 batches up to 32 pages in a single I/O.

When Db2 writes a changed page to disk, it cross-invalidates the page using the group buffer pool. These cross-invalidations are called explicit cross-invalidations. These explicit cross-invalidations are reported in statistics separately from cross-invalidations caused by directory reclaims or by writes of a changed page to a group buffer pool.

Writing to a duplexed group buffer pool

When a group buffer pool is duplexed, page writes are performed in the following manner:
  1. For some fixed number of pages that must be written:
    1. Each page is written to the secondary group buffer pool asynchronously
    2. Each page is written to the primary group buffer pool synchronously
  2. After all pages have been written to the primary group buffer pool, Db2 checks to see if all pages have been written to the secondary group buffer pool. If some pages still need to be written, Db2 forces the completion of those writes.