Chapter 6. Recovery 179
An application using DB2 notifies that it has reached a point of consistency using a commit
point. DB2 does not proceed beyond a commit point until it has ensured that all work done
before the commit point is fully protected against loss or invalidation.
TSO applications notify a commit point using SQL COMMIT statement.
IMS and CICS applications establish a sync point to establish a point of consistency.
To commit work in RRSAF applications, you can use the CPIC SRRCMIT function or the
DB2 COMMIT statement. To roll back work, you use the CPIC SRRBACK function or the
DB2 ROLLBACK statement. See DB2 UDB for z/OS Version 8 Application Programming
and SQL Guide, SC18-7415-03.
All applications can use the rollback function to intentionally back out all data changes
since the last commit point or application savepoint.
When DB2 restarts after an abnormal termination (see also 6.7, “DB2 subsystem restart after
abend” on page 211):
IN DOUBT threads are resolved.
All uncommitted database changes are backed out.
Committed changes that might not have been applied to disk are reapplied to ensure
consistency of data.
All committed database changes cannot be backed out.
6.3 Unit of recovery
A unit of recovery is the work, done by a single DB2 DBMS for an application, that changes
DB2 data from one point of consistency to another. 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 and
ends at a later point of consistency.
Unit of recovery (UR) is the information required for DB2 to backout all the application
database changes since the last commit point. DB2 records all recovery information in a DB2
recovery log, which is made up of the active log and the archive log. These logs contain
chronological entries that record significant DB2 activities of all users and jobs. The only
exceptions are database changes done by utilities with LOG NO where the backup copies
done with the COPY utility are absolutely essential for recovery to a consistency point prior to
the execution of the utility.
Dual active logs and dual archive logs are strongly recommended to avoid recovery failures
due to media failures. Changes are not updated to disk but queued in the log buffer until either
commit or a buffer pool write threshold has been reached. If the same disk record is updated
before the media is updated, the buffer is altered to reflect both changes. The archive logs are
recorded in the bootstrap data set (BSDS). The total number of BSDS archive log entries is
limited by the DSNZPARM parameter MAXARCH. Other DSNZPARM parameters related to
active and archive logs are TWOACTV and TWOARCH.
In the data sharing environment, DB2 uses “a force-at-commit” policy for updates against
page sets that are dependent on group buffer pool GBP. See 5.6.1, “Data sharing
implications” on page 168 for the DB2 structures in the coupling facility. GBP caches data and
maintains data consistency for group members.
DB2’s role in a commit process as coordinator or participant is determined by the application:
In TSO applications, DB2 acts as the commit coordinator, see 6.3.1, “Commit processing
for TSO applications” on page 180.