log of DB2 --excerpt

Units of recovery and points of consistency
A unit of recovery begins with the first change to the data after the beginning of the
job, or following the last point of consistency. The unit of recovery ends at a later
point of consistency.
A unit of recovery is the work that changes DB2 data from one point of
consistency to another. This work is done by a single DB2 DBMS for an
application. The point of consistency (also referred to as sync point or commit point)
is a time when all recoverable data that an application program accesses is

consistent with other data.

How DB2 rolls back work
If failure occurs within a unit of recovery, DB2 rolls back (backs out) any changes
to data. Rolling back returns the data to its state at the start of the unit of recovery;
that is, DB2 undoes the work.
For a partition-by-growth table space, if a new partition was added in the unit of
recovery, any uncommitted updates can be backed out, but the physical partition is
not deleted.

The possible events that trigger "Begin rollback" in this figure include:
v SQL ROLLBACK statement
v Deadlock (reported as SQLCODE -911)

v Timeout (reported as SQLSTATE 40001)

An operator or an application can issue the CANCEL THREAD command with the
NOBACKOUT option to cancel long-running threads without backing out data
DB2 backs out changes to catalog and directory tables regardless of the
NOBACKOUT option.
How DB2 creates log records
Log records typically go through a standard life cycle.
1. DB2 registers changes to data and significant events in recovery log records.
2. DB2 processes recovery log records and breaks them into segments if necessary.
3. Log records are placed sequentially in output log buffers, which are formatted as
VSAM control intervals (CIs). Each log record is identified by a continuously
increasing RBA in the range 0 to 248-1, where 248 represents 2 to the 48th power.
(In a data sharing environment, a log record sequence number (LRSN) is used
to identify log records. See DB2 Data Sharing: Planning and Administration for
more information.)
4. The CIs are written to a set of predefined disk active log data sets, which are
used sequentially and recycled.
5. As each active log data set becomes full, its contents are automatically offloaded
to a new archive log data set.
If you change or create data that is compressed, the data logged is also
compressed. Changes to compressed rows that result from inserts, updates, and
deletes are also logged as compressed data. Updates to compressed indexes are not
logged as compressed data.
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 ZPARMs are set 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:
v Phase 1 commit
v Abort processing
v GBP-dependent index split
v Mass delete in a data-sharing environment
v Use of GBPCACHE NO
v 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.
How DB2 writes (offloads) the archive log
The process of copying active logs to archive logs is called offloading.
The relationship of offloading to other logging events is shown schematically in the
following figure.
Write to
active log----->
                    Triggering
                     event

                        |

                         Offload process-->

                          ---------->                       Write to  archive log
                          ---------->                      Record on BSDS
During the process, DB2 determines which data set to offload. Using the last log
relative byte address (RBA) that was offloaded, as registered in the BSDS, DB2
calculates the log RBA at which to start. DB2 also determines the log RBA at which
to end, from the RBA of the last log record in the data set, and registers that RBA
in the BSDS.
When all active logs become full, the DB2 subsystem runs an offload and halts
processing until the offload is completed. If the offload processing fails when the
active logs are full, DB2 cannot continue doing any work that requires writing to
the log.
What triggers an offload
An offload of an active log to an archive log can be triggered by several events.
The most common situations that trigger an offload include:
v An active log data set is full.
v DB2 starts, but an active log data set is full.
v The ARCHIVE LOG command is issued.
An offload can be also triggered by two uncommon events:
v An error occurs while writing to an active log data set. The data set is truncated
before the point of failure, and the record that failed to write becomes the first
record of the next data set. An offload is triggered for the truncated data set as
in a normal end-of-file condition. With dual active logs, both copies are
truncated so the two copies remain synchronized.
v The last unarchived active log data set becomes full. Message DSNJ110E is
issued, stating the percentage of its capacity in use; IFCID trace record 0330 is
also issued if statistics class 3 is active. If all active logs become full, DB2 issues
the following message and stops processing until offloading occurs.
DSNJ111E - OUT OF SPACE IN ACTIVE LOG DATA SETS
ref  

db2 redbook