Using the recovery utility

The recovery utility (DFSURDB0) recovers partition data sets. The partition is restored from the image copy, and logs are applied for updates since the image copy. Change accumulation can be done to sort the log records by RBA within partition to speed database recovery.

DBRC authorization fails when multiple recovery jobs are authorized to the same database. DFS047A authorization failure messages with return code 15 and Abend U047 result when attempting to recover multiple partitions at the same time.

DBRC authorization prevents more than one recovery job from being authorized to a registered database for both multiple data set groups and partitioned databases.

Allocate partition data sets on separate DASD volumes to avoid the necessity of recovering more than one partition after a hardware failure.

Using Timestamp Recovery

Point-in-time recovery is useful to restore a database to a point other than the current time. It is very important that all partitions be recovered to the same timestamp to keep the database consistent. This is especially important when there are any indexes or logical relationships.

Using Database Backout

Use PSB to backout database changes for both dynamic and batch backout. It is likely that multiple partitions were updated by the application and need to be backed out.

Using the Database Pre-Reorganization Utility

Before loading or reorganizing a database with logical relationships, run the Database Pre-reorganization Utility to build the DFSURCDS input data set. You still use this utility for partitioned databases if logical relationships exist in the DBD.

Using the Scan Utility

The rules for logical relationships between partitioned databases ensure that there are no pointers between partitioned databases that can be affected by reorganization. You do not need the scan utility when reorganizing logically related partitioned databases. However, a partitioned database can have a pointer to a logically related nonpartitioned database. Therefore, the Scan utility is still necessary when reorganizing a nonpartitioned database that is logically related to a partitioned database using logical parent or logical child pointers.

The Scan utility may still be used for logically related partitioned databases if the counter in the logical parent needs to be updated when the logical child database is initially loaded, but the logical parent database already exists.