How Db2 writes the active log

Db2 writes the log buffers to an active log data set in response to several conditions. The most common condition is that the Db2 subsystem forces the log buffer to be written.

Db2 also writes the log buffers to an active log data set when they become full, or when the write threshold is reached.

When Db2 forces the log buffer to be written (such as at commit time), the same control interval can be written several times to the same location.

Be sure to set your subsystem parameters so that there are enough log buffers to avoid the need to wait for a buffer to become available (DSN6LOGP OUTBUFF parameter). Switching log data sets may also cause a temporary performance impact when the switch takes place and the associated recovery checkpoint is taken. This can be minimized by ensuring that the active log data sets are large enough to avoid frequent switching. In addition, some events can cause log buffers to be written before the ZPARM-defined threshold has been reached. These events include, but are not limited to:

• Phase 1 commit
• Abort processing
• GBP-dependent index split
• Mass delete in a data-sharing environment
• Use of GBPCACHE NO
• All log buffers being filled

Consider the probable frequency of these events when you determine how often to commit changes.

When Db2 is initialized, the active log data sets that are named in the BSDS are dynamically allocated for exclusive use by Db2 and remain allocated exclusively to Db2 (the data sets were allocated as DISP=OLD) until Db2 terminates. Those active log data sets cannot be replaced, nor can new ones be added, without terminating and restarting Db2. The size and number of log data sets is indicated by what was specified by installation panel DSNTIPL. The use of dual active logs increases availability as well as the reliability of recovery by eliminating a single point of failure.