Data Integrity with DB2 for z/OS

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.