Recovering from unequal timestamps on BSDSs

When timestamps on different copies of the bootstrap data set (BSDS) differ, Db2 attempts to resynchronize the BSDSs and restore dual BSDS mode. If this attempt succeeds,Db2 restart continues automatically. If this attempt fails, you need to recover from the situation.

Symptoms

The following message is issued:

DSNJ120I - DUAL BSDS DATA SETS HAVE UNEQUAL TIMESTAMPS,
           BSDS1 SYSTEM=..., UTILITY=..., BSDS2 SYSTEM=..., UTILITY=...

Causes

Unequal timestamps can occur for the following reasons:

One of the volumes that contains the BSDS has been restored. All information of the restored volume is outdated. If the volume contains any active log data sets or Db2 data, their contents are also outdated. The outdated volume has the lower timestamp.
Dual BSDS mode has degraded to single BSDS mode, and you are trying to start without recovering the bad copy of the BSDS.
The Db2 subsystem abended after updating one copy of the BSDS, but prior to updating the second copy.

Resolving the problem

Operator response: If Db2 restart fails, notify the system programmer.

System programmer response:

If Db2 fails to automatically resynchronize the BSDS data sets:

Run the print log map utility (DSNJU004) on both copies of the BSDS; compare the lists to determine which copy is accurate or current.
Rename the outdated data set, and define a replacement for it.
Copy the good data set to the replacement data set, using the REPRO command of access method services.
Use the access method services REPRO command to copy the current version of the active log to the outdated data set if all the following conditions are true:
- The problem was caused by a restored outdated BSDS volume.
- The restored volume contains active log data.
- You were using dual active logs on separate volumes.
If you were not using dual active logs, cold start the subsystem.

If the restored volume contains database data, use the RECOVER utility to recover that data after successful restart.