Before running RESTORE SYSTEM

Certain activities might be required before you run the RESTORE SYSTEM utility, depending on your situation.

Complete the following steps prior to running RESTORE SYSTEM:

  1. Stop DB2®. If data sharing, stop all DB2 members in the group.
  2. Run DSNJU003 (Change Log Inventory) to create a DB2 conditional restart record with the CRESTART SYSPITR option. Specify the log truncation point with the SYSPITR option that corresponds to the point in time to which the system is to be recovered.

    For data sharing, specify an LRSN value. For non data sharing, specify an RBA value.

    If you restored the log copy pool and the active log data sets are stripped or the log copy pool is for a data sharing environment, you must specify the data complete LRSN during the conditional restart in the following scenarios:
    • You are cloning a DB2 system by using a system-level backup as the source. In this case, conditionally restart DB2 with an ENDRBA or ENDLRSN that is equal to the data complete LRSN of the system-level backup.
    • You are performing a system-level point-in-time recovery. In this case, conditionally restart DB2 with the log truncation point equal to or less than the data complete LRSN of the system-level backup. Use the data complete LRSN as the CRESTART ENDRBA, ENDLRSN, or SYSPITR log truncation point.
    You can determine the data complete LRSN from the following places:
    • Message DSNU1614I, which is generated when BACKUP SYSTEM completes successfully
    • The report generated by the print log map utility (DSNJU004)
  3. Start DB2. When the DB2 restart processing for the conditional restart with the SYSPITR option completes, DB2 enters system RECOVER-pending and access maintenance mode. During system RECOVER-pending mode, you can run only the RESTORE SYSTEM utility.
  4. Ensure that all data sharing members that were active at the SYSPITR log truncation point (or restarted after this point) have been restarted with the same SYSPITR LRSN value. You can stop the other members of the data group (with MODE(QUIESCE)) after the SYSPITR restart.
  5. Start of changeEnsure that the ICF catalogs for the DB2 data are not active and are not allocated. The ICF catalog for the data must be on a separate volume than the ICF catalog for the logs. The command to unallocate the catalog is F CATALOG,UNALLOCATE(catalog-name). Alternatively, if you add the ICF catalog names to the database copy pool definition by altering the copy pools, the catalog is unallocated by HSM before doing the restore.End of change
Related information:

How to determine which system-level backups DB2 restores

The RESTORE SYSTEM utility uses the most recent system-level backup of the database copy pool that DB2 took before the SYSPITR log truncation point.

To determine whether the system level backup will be restored from disk or from tape:
  • If FROMDUMP was not specified and the system-level backup resides on disk, DB2 uses it for the restore.
  • If you specify YES in the RESTORE/RECOVER FROM DUMP field on installation panel DSNTIP6 or you specify the FROMDUMP option in the RESTORE utility statement, restore uses only the dumps on tape of the database copy pool.
  • If you specify a dump class name on the DUMP CLASS NAME field on installation panel DSNTIP6 or you specify the DUMPCLASS option in the RESTORE utility statement, DB2 restores the database copy pool from the DFSMshsm dump class.
  • If you do not specify a dump class name in the DUMP CLASS NAME field on installation panel DSNTIP6 or you do not specify the DUMPCLASS option in the RESTORE utility statement, RESTORE SYSTEM issues the DFSMShsm LIST COPYPOOL command and uses the first dump class listed in the output.

Start of changeThe RESTORE SYSTEM utility invokes DFSMS to restore the database copy pool volumes from a system-level backup on tape. If the z/OS® level is Version 1 Release 11 or earlier, the utility invokes DFSMSdss. If the z/OS level is Version 1 Release 12 or later, the utility invokes DFSMShsm.End of change

How to determine if RESTORE SYSTEM uses parallelism when restoring from tapes

Parallelism occurs if the dumps of the volumes in the database copy pool reside on different tape volumes. The degree of parallelism is limited by:
  • The TAPEUNITS option, which limits the number of tape units that the utility can allocate.
  • The number of distinct tape volumes that the dump resides on.

Determining whether the system-level backups reside on disk or tape

Restoring each volume in the database copy pool from a fast replication copy on the disk occurs virtually instantaneously. Restoring the database copy pool from dumps on tape volumes takes much longer.

To determine whether the system-level backups of the database copy pool reside on the disk or tape:
  1. Run the DFSMShsm LIST COPYPOOL command with the ALLVOLS option.
  2. Run the DSNJU004 utility output. For data sharing, run the DSNJU004 utility output on each member.
  3. Review the output from the DFSMShsm LIST COPYPOOL command with the ALLVOLS option.
  4. Review the DB2 system-level backup information in the DSNJU004 utility output.

If the system-level backup chosen as the recovery base for the database copy pool no longer resides on DASD and the FROMDUMP option has not been specified, then the RESTORE SYSTEM utility will fail. You can then specify the RESTORE SYSTEM FROMDUMP option, or specify it on installation panel DSNTIP6, to direct the utility to use the system-level backup that was dumped to tape.