Coordinated IMS and DB2 disaster recovery overview
With coordinated IMS and DB2 DR, the idea is to restore IMS and DB2 to a consistent point in time between both IMS and DB2. This is a difficult challenge because there is no overt communication between IMS and DB2 that would create a consistent point between the two. The storage-mirroring solutions are good at maintaining consistency between products like IMS and DB2 because the storage processors are unconcerned with applications like IMS and DB2. Instead, they maintain consistency of volume data. For DR solutions that are not doing storage mirroring, the consistent point in time between IMS and DB2 at the production site must be established for it to be used at the remote site.
For non-storage mirroring environments, there are two ways to do coordinated DR for IMS and DB2. In both ways, the IBM tools products, IMS Recovery Expert and DB2 Recovery Expert, are used. The first strategy is Coordinated IMS and DB2 Restart from a Combined SLB, and the second is Coordinated IMS and DB2 Restart from Separate SLBs with Log Apply.
In the first solution, the production volumes for IMS and DB2 are discovered and used as input to IMS Recovery Expert or DB2 Recovery Expert to form the basis for the SLB. In essence, this combined SLB contains production data for both IMS and DB2, as shown in Figure 1. When the job is run to create the combined SLB, it does a FlashCopy for a consistency group, where all IMS and DB2 volumes are flash-copied to the same point in time. The storage processors, together with the dependent write processes within IMS and DB2, ensure that all volumes in the combined SLB are consistent to the same point in time. At the specific point in time of the FlashCopy, it is likely there will be uncommitted updates in both the IMS and DB2 databases. These updates are backed out at the remote site after the combined SLB is restored. For IMS, dynamic back-out is used during emergency restart. For DB2, undo/redo processing is used when DB2 is started. The production DBRC RECON data set included in the SLB is used for restart, and it does not need to be conditioned because it is done with other DR solutions since IMS is just being restarted, and there is no database recovery activity. A restart for IMS and DB2 from an SLB is just like restarting IMS and DB2 following a power failure.
Figure 1. Coordinated IMS and DB2 Combined SLB (primary site activity)
In the second solution, the production volumes for IMS and DB2 are discovered and treated separately. An SLB is created for IMS and another for DB2 at different points in time. The FlashCopy for a consistency group ensures that there are consistent points for IMS and DB2 individually. Together, the SLBs are sent to the remote site, as shown in Figure 2. In addition to the SLBs, archived logs for IMS and DB2 are sent to the remote site. The timestamps of the archived logs are recorded by the IMS Recovery Expert and DB2 Recovery Expert products in their respective repositories for use at the remote site. Prior to restoring the SLBs for IMS and DB2 at the remote site, the latest archived log timestamps are determined for IMS and DB2 to determine which time to use for recovering the database data sets. The timestamp selected is the earlier of the last two archived log times for IMS and DB2. With PITR, only committed updates are applied to the database data sets, so a cold start is all that is required for IMS and a restart for DB2.
Figure 2. Coordinated IMS and DB2 SLB with PITR using archived logs (primary site activity)