DB2 UDB for z/OS Version 8 Performance Topics - IBM Redbooks

BACKUP SYSTEM
During backup DB2 records the “recovery base log point” (RBLP) in the header page of
DBD01. The RBLP is identified as the most recent system checkpoint prior to a backup log
point, and the point at which DB2 starts scanning logs during a RESTORE SYSTEM recovery
operation. DB2 updates its BSDS (boot strap data set) with backup version information and
can keep track of up to 50 backup versions. In the case of data sharing the submitting
member records the backup version in its BSDS and also in the SCA. This information is also
recorded in DFSMShsm control data sets.
Note that in DB2 V8, the SET LOG SUSPEND command also writes the RBLP to the DBD01
header page.
Concurrency and compatibility
BACKUP SYSTEM can run concurrently with any other utility; however, it must wait for the
following DB2 events to complete before the copy can begin:
► Extending data sets
► Writing 32 KB pages for page sets with a VSAM CISZE that is different from the DB2 page
size
► Writing close page set control log records
► Creating data sets (for table spaces, indexes, and so forth)
► Deleting data sets (for dropping tables spaces, indexes, and so forth)
► Renaming data sets (for online reorganizing of table spaces, indexes, and so forth during
the SWITCH phase)
Only one BACKUP SYSTEM job can be running at one time.
The log write latch is not obtained by the BACKUP SYSTEM utility, as is done by the SET
LOG SUSPEND command. Therefore, using the BACKUP SYSTEM utility should be less
disruptive in most cases. There is no need to suspend logging when using the BACKUP
SYSTEM utility, since DB2 is now in control of taking the volume copies, where you are in
charge of initiating copying the data in the case of using -SET LOG SUSPEND.
RESTORE SYSTEM
Use the RESTORE SYSTEM utility only when you want to recover a subsystem or data
sharing group to an arbitrary point-in-time. The utility restores only the database copy pool of
a data only or full system backup, and then applies logs until it reaches a point in the log equal
to the log truncation point specified in a point-in-time conditional restart control record
(SYSPITR CRCR) created with DSNJU003. You cannot explicitly name the backup to use for
recovery. That is implicitly determined by the log truncation point used to create the SYSPITR
CRCR. Similar to the Recovery utility, Restore can optionally use the Fast Log Apply (FLA)
option. As restore will be the only task running in DB2, we strongly advise you to enable Fast
Log Apply in order to accelerate the recovery process.
RESTORE SYSTEM LOGONLY can run without a BACKUP SYSTEM backup and can run
with z/OS 1.3. By using this option, you indicate that the database volumes have already
been restored using DFSMShsm or other means, and the restore phase will be skipped. A
backup made in a SET LOG SUSPEND/RESUME cycle is required because SET LOG
SUSPEND updates the RBLP in the DBD01 header page.
DB2 V8 Fast Log Apply behavior
Fast Log Apply was introduced in DB2 V6. It is activated by specifying a non-zero value for
the DSNZPARM parameter LOGAPSTG. The acceptable values are 0 to 100 MB with 100
220 DB2 UDB for z/OS Version 8 Performance Topics