IMS local recovery (PITR)
The SLB has multiple uses. It can be used to restore an entire IMS subsystem in a DR solution, and it can also be used as a replacement for most image copies used for local application recovery. With DR, the full SLB is generally restored, but with local application recovery, only one or more databases may need to be restored and recovered. In this demonstration, we show how a group of databases can be recovered using PITR to any timestamp. A PITR recovery requires functionality that is not included in the IMS base product. In our demonstration, we do a PITR recovery using the IMS Database Recovery Facility (DRF) utility, which is found in the IMS Recovery Solution Pack.
The local application profile was created during IMS Recovery Expert one-time setup, as explained earlier. This is where the local recovery options were identified (recovery and image copy utilities, for example). This is also where the recovery job was created.
In this demonstration, we create a full SLB for all IMS production resources. Next, we start two BMPs that commit updates to a database. Then we start a third BMP that updates a database and artificially waits before committing the update. In the demonstration, we make the decision that there was an application error during the processing of the third BMP as shown in Figure 15.
Figure 15. Create committed and uncommitted updates with BMPs
Since we are doing a PITR to a timestamp, we use the IMS Recovery Expert ISPF interface to specify the timestamp for the recovery. The timestamp selected was during the processing of the third BMP after some updates were done, but before the CHKP call was issued. The specification of this timestamp and that a PITR recovery is wanted is shown in Figure 16.
Figure 16. Use IMS Recovery Expert ISPF interface to select timestamp for PITR
The application profile is then updated after the timestamp and PITR is specified. The original recovery job built during one-time setup will pick up the recovery timestamp from the application profile saved in the IMS Recovery Expert repository, so no modifications need to be made to the recovery JCL.
The recovery job (RECOVERY) was prebuilt during the IMS Recovery Expert one-time setup as shown in Figure 1. This recovery job will drive the IMS Database Recovery Facility (DRF), which is available in the IMS Recovery Solution Pack, to do PITR recovery, as shown below.
Figure 17. Drive IMS DRF to perform PITR to timestamp selected
There are a couple of interesting things to point out regarding this local application recovery. First, we can see in the IMS DRF recovery report, shown in Figure 18, that a PITR recovery was requested, and the timestamp specified for the PITR is the same timestamp we save in the application profile.
Second, the SLB was created before the BMPs were initiated, and there were also some image copies created for some of the database data sets after the SLB. With IMS Recovery Expert, the databases are recovered using the SLB or a later image copy. DRF will apply any updates on the log data sets, along with an image copy or directly to a database data set. In our demonstration, the databases in the recovery group have a mixture of SLB and image copies available for the recovery. For example, the databases (DBHIO, DBHIOI, DBHIOS1, and DBHIOS2), have an image copy that is later than the SLB. The database (DBHDV) does not have a later image copy, so the recovery will use the SLB. Both databases will use the log data sets in the recovery. We can see in the IMS DRF recovery report, as shown in Figure 18, that some database data sets used image copies, and others only applied logs to data sets restored from the SLB in the prior step.
Figure 18. Show IMS DRF output report for PITR
After the PITR completes, we run a job (DBAFRECV) to show all DB records in the databases. We can see that the databases contain all the DB records inserted by the two BMPs that completed prior to the timestamp specified in the application profile. We can also see that none of the segments inserted by the third BMP but not committed prior to the timestamp specified are in the databases.