Exploring IMS disaster recovery solutions, Part 4: Coordinated IMS and DB2 solutions

Every customer needs a disaster recovery (DR) plan. The strategy will differ from one customer to the next. For IMS®, there are two types of DR solutions: IMS-specific and storage mirroring. Here in Part 4, we explore the IMS-specific DR solutions. There are solutions that use only the IMS base product and solutions that use the IBM® IMS Tools products. For each DR solution, there will be a discussion of the key concepts related to that solution.

Share:

Glenn Galler (gallerg@us.ibm.com), Certified IT IMS Specialist, IBM China

Glenn GallerGlenn Galler is a certified IT specialist for the IMS product in the IBM Advanced Technical Skills (ATS) group. He is a senior programmer specializing in disaster recovery. He joined the ATS group in March 2007. Galler is also the campus recruiting manager for the IBM Software Group for the University of Michigan, holding this position since 1998. He joined IBM in 1982 receiving his bachelor's degree in computer science from the University of Michigan. In 1989, he received a master's degree in computer engineering from the University of Santa Clara. Galler has worked in many areas of IMS, including testing, development, marketing and management. From 1992 to 1997, he held an international assignment in England as the European program manager for the IMS Quality Partnership Program (QPP).



Ron Bisceglia (RBisceglia@rocketsoftware.com), Lead Software Developer, Rocket Software

Ron BiscegliaRon Bisceglia is a lead software developer for Rocket Software, based in Houston. He has worked with IMS for more than 24 years, and for the past 20 years has been involved in the design, development, and support of a range of IMS tools. He has been involved in the development of database reorganization utilities, data propagation tools, database monitoring and analysis solutions, data replication, and backup and recovery products.



03 May 2012

Before you start

About this series

Are you concerned with your ability to recover your business data successfully in an acceptable amount of time for your IMS databases? This "Exploring IMS Disaster Recovery Solutions" series covers the non-storage mirroring disaster recovery solutions for the IMS environment. The methods described in this series show how various backup and recovery resources can be combined to reduce time and data loss in the event of a disaster. Storage-based fast replication techniques (like FlashCopy technology) are also shown in this series with storage-aware IMS Tools that allow a coordinated and consistent recovery point between IMS and DB2 databases.

About this tutorial

This tutorial describes the IMS Disaster Recovery solutions that use the IMS Tools product, IMS Recovery Expert, and DB2® Tools product, DB2 Recovery Expert, to provide a consistent recovery point between IMS and DB2 production environments. The SLB is created using storage-based fast replication, such as FlashCopy technology, to ensure that IMS and DB2 are unavailable for only a couple of seconds or less.

The coordinated IMS and DB2 Disaster Recovery solutions discussed are:

  • IMS and DB2 Restart from a Combined SLB Only
  • IMS and DB2 Point-In-Time-Recovery (PITR) and Restart from Separate SLBs with Log Apply

For each coordinated disaster recovery (DR) solution, there is a section showing the one-time customization steps for IMS Recovery Expert and DB2 Recovery Expert.

If you haven't done so already, consider downloading the IMS Disaster Recovery demonstrations.

Objectives

After completing the tutorial, you should be able to:

  • Customize the IMS Recovery Expert and DB2 Recovery Expert product
  • Create disaster and application profiles
  • Create a system-level backup (SLB)
  • Understand how PITR works
  • Understand the coordinated IMS and DB2 disaster recovery process

Prerequisites

To understand the material presented here, you should have the following:

  • Basic understanding of the z/OS® environment
  • Basic knowledge of the IMS and DB2 operating environments
  • Basic knowledge of IMS and DB2 commands and procedures
  • Basic knowledge of an Internet browser, such as Firefox or Internet Explorer

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)
Diagram shows separate DB2 and IMS volumes on left, and shows them combined in a single volume on the right in combined SLB

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)
Diagram shows IMS transmitted on left with SLB and DB2 transmitted on the right with SLB

Coordinated IMS and DB2 disaster recovery (combined SLB, one-time)

Coordinated IMS and DB2 restart from a combined SLB (one-time setup)

Primary site activities

The coordinated IMS and DB2 DR (combined SLB only) demonstration has a few one-time setup steps for the IMS Recovery Expert and DB2 Recovery Expert products, as shown in Figure 3. For example, the following steps are performed:

  1. Register IMS and DB2 systems
  2. Analyze the IMS and DB2 configuration
  3. Define the system backup profile for IMS and DB2
  4. Define the DR profile for IMS and DB2

The steps to register the IMS and DB2 systems are done in each product.

Figure 3. IMS and DB2 one-time setup (primary site activity)
Image shows the steps in IMS and the steps in DB2

The profiles can be created with either product, but in this demonstration, the profiles are created with the IMS Recovery Expert product. Thus, the DB2 volumes identified during the configuration analysis step are identified to the IMS Recovery Expert product so they can be combined with the IMS volumes. Figure 4 shows the DB2 volumes identified. These volumes will need to be added to the backup profile for the IMS system so that both DB2 and IMS data are contained in the same SLB.

The heart of the one-time setup is in the creation of the backup profiles. A backup profile is used to define the data that will be included in an SLB. Since we are creating the backup profile in IMS Recovery Expert the volumes where IMS data sets reside can automatically be discovered by IMS Recovery Expert and included in the SLB. For the DB2 volumes, we must include the volumes discovered during the configuration analysis step, as shown in Figure 4 in the backup profile. The process of including these volumes in the backup profile is shown in Figure 5.

Figure 4. Display DB2 production volumes discovered during system analysis (primary site activity)
Screen cap shows volumes used by this subsystem
Figure 5. Combined DB2 and IMS volumes displayed by IMS Recovery Expert ISPF interface (primary site activity)
Screen cap shows volumes displayed

Backup profiles allow the user to identify the target pool and the offload options, including whether the volumes are to be copied to tape, compressed, or encrypted. The backup and recovery JCL jobs are also created at this time. In our demonstration, the JCL to create the backup profile is called PROSETUP; the JCL to create the SLB during the runtime demonstration is called CREATSLB; and the JCL to create the remote DR PDS data set with the recovery JCL for the remote site is called DRESTART. This is shown in Figure 6.

Figure 6. Create SLB and DR profiles (primary site activity)
Image shows ISPF, function, description, JCL created, job output, and steps for each

Coordinated IMS and DB2 disaster recovery (combined SLB, runtime)

Coordinated IMS and DB2 restart from a combined SLB (primary site)

Primary site activities

The coordinated IMS and DB2 DR (combined SLB only) demonstration shows how an SLB can be created for the combined set of IMS and DB2 production volumes. In this demo, the combined SLB is created twice to demonstrate two important features of the IMS Recovery Expert and DB2 Recovery Expert products. When the first SLB is created, the IMS and DB2 volumes are the same as those mapped during the one-time setup. After the first SLB is created, a new database data set is created on a new volume that was not part of the original production volumes. One option selected during one-time setup is Validate IMS Vols. By putting Y for this option, as shown in Figure 7, this new volume is automatically detected and included in the backup when the second SLB is created.

Figure 7. IMS and DB2 one-time setup validation option (primary site activity)
Screen cap shows Y selected for validate IMS vols

Preparing for DR with a combined SLB approach is a two-step process. The first step is to run the CREATSLB job created during one-time setup. The second step is to run the DRESTART job, which was also created during one-time setup. Together, these jobs create the SLB and the remote DR PDS data set with the recovery jobs for the remote site. The SLB and remote DR PDS data set are sent to the remote site. These steps are shown in Figure 8.

Figure 8. First combined IMS and DB2 SLB (primary site activity)
Image shows combined IMS and DB2 SLB steps

After the first SLB is created, a new database data set is created on a volume that was not included in the previous SLB. When the second SLB is created, we will show how a target volume is mapped automatically for this new volume, ensuring that all IMS production volumes are included in the FlashCopy for a consistency group used to create the SLB.

Prior to creating the second SLB, there are two BMPs started (IMSDB2B2 and IMSDB2B3). The updates in these BMPs are against both IMS and DB2 in the same unit of recovery (UOR). IMSDB2B2 does one insert followed by a checkpoint about every half a second.

This BMP will be momentarily paused by the FlashCopy for a consistency group when the volumes it needs to write to are frozen. This occurs just after CHKP 03630 at timestamp 22:41:52.226650 and prior to CHKP 0361 at timestamp 22:41:52.847190, as shown in Figure 9.

Figure 9. Key timestamps for BMP IMSDB2B2 (primary site activity)
Image shows key timestamps for IMSDB2B2

The second BMP, IMSDB2B3, is paused with a WTOR after the insert and prior to the checkpoint CHKP 00110 at timestamp 22:40:58.532765 and prior to CHKP 00111, as shown in Figure 10. The purpose of this BMP is to show that any uncommitted updates at the time the SLB is created will be backed out by IMS and DB2 during restart.

Figure 10. Key timestamps for BMP IMSDB2B3 (primary site activity)
Image shows key timestamps for BMP IMSDB2B3 (primary)

The key timestamps shown in Figure 9 are specific points in time relative to the creation of the SLB and FlashCopy for a consistency group. The I/O suspend time is the time when the I/O is suspended for the first volume in the consistency group. The backup time is the time when the I/O is suspended for the last volume in the consistency group. The I/O resume time is the time when I/O is resumed for all volumes in the consistency group. The volumes are not suspended all at once; they are suspended in a rolling fashion. This means that I/O can continue on an unsuspended volume even if another volume in the consistency group has already been suspended. However, once I/O has been suspended on a volume, it cannot be updated until after the I/O resume time has occurred. For the first BMP (IMSDB2B2), the last checkpoint (CHKP 03630) occurred at 22:41:52.226650, which was after the I/O suspend time, while the next checkpoint (CHKP 03631), which was created after the SLB was created, occurred at 22:41:51.847190, which is after the I/O Resume Time of 22:41:52:426498.

The key timestamps shown in Figure 10 are for the second BMP (IMSDB2B3). The last checkpoint (CHKP 00110), which occurred at 22:40:58.532763, occurred well before the I/O Suspend Time because we held up the next checkpoint (CHKP 00111) with a WTOR after the insert was completed and before the checkpoint was done. We released the WTOR after the SLB was created, which was after the I/O Resume Time at 22:41:52.426498. Thus, the next checkpoint (CHKP 00111) occurred at 22:50:09.884477.

These key timestamps can also be seen in the output of the CREATSLB job, as shown in Figure 11.

Figure 11. Key timestamps in IMS Recovery Expert report for second SLB (primary site activity)
Image shows that backup summary report includes key timestamps

The only additional key time in this output report is the backup elapsed time, which is calculated as the difference between the I/O resume time and the I/O suspend time. In our simple test environment where we had only 26 volumes being FlashCopied, we have a backup elapsed time of only 0.28 seconds. Generally speaking, even in a production environment with several hundred volumes, the backup elapsed time should be under 1 second.

The CREATSLB output report also shows how the validation step identified the new volumes (IA7D32 and IA7D42) and dynamically mapped them to target volumes in the storage group. This can be seen in Figure 12. Once again, the DRESTART is run after the CREATSLB job is completed to build the recovery jobs for the remote site in the DR PDS data set.

Figure 12. Target validation in IMS Recovery Expert Report for second SLB (primary site activity)
Image shows CREATSLB output report

Coordinated IMS and DB2 restart from a combined SLB (remote site)

Remote site activities

At the remote site, the DR PDS data set is restored and the only job that needs to be run is called ssid#JC1. In our demonstration, the IMS SSID is IAA3, so the job is called IAA3#JC1. While the member name is IAA3#JC1, the actual job name in the member is DREMOTE, as seen in Figure 13.

Figure 13. Recovery job IAA3#JC1 (DREMOTE) for combined SLB (remote site activity)
Image shows IMS and DB2 IAA3#JC1 (DREMOTE) (remote)

The DREMOTE job restores the IMS Recovery Expert repository, as well as the SLB. In our demonstration, the SLB is restored from offloaded tapes created by the CREATSLB step at the primary site, as in Figure 14.

Figure 14. IMS Recovery Expert recovery job output (remote site activity)
Image shows IMS and DB2 DREMOTE output (remote)

With the SLB and IMS Recovery Expert repository restored, IMS and DB2 can be restarted. IMS is restarted with an emergency restart so that dynamic back-out can back out the uncommitted updates. DB2 must do UNDO/REDO processing during its restart to remove its uncommitted updates. The IMS and DB2 restarts are shown in Figure 15.

Figure 15. IMS and DB2 restart (remote site activity)
Image shows IMS and DB2 restart (remote)

The dynamic back-out for IMS is shown in Figure 16, while the UNDO/REDO processing for DB2 is shown in Figure 17.

Figure 16. IMS dynamic back-out during emergency restart (remote site activity)
Image shows IMS dynamic backout (remote)
Figure 17. UNDO/REDO processing during DB2 restart (remote site activity)
Image shows DB2 dynamic back-out (remote)

After the back-outs are performed, the databases are displayed, and the last insert for the BMP (IMSDB2B2), which was check-pointed prior to the creation of the SLB was CHKP 03360, is in the database as shown in Figure 18.

Figure 18. IMS and DB2 database-committed updates BMP IMSDB2B2 (remote site activity)
Image shows IMS and DB2 database-committed updates (remote)

The last insert for the BMP (IMSDB2B3), held up prior to being check-pointed, was CHKP 00111. This insert was backed out during dynamic back-out. The last committed update for the BMP (IMSDB2B3) was CHKP 00110 and is in the database as shown in Figure 19.

Figure 19. IMS and DB2 database-committed updates BMP IMSDB2B3 (remote site activity)
Image shows IMS and DB2 database-committed updates (remote)

Coordinated IMS and DB2 disaster recovery (separate SLBs with log apply, one-time)

Coordinated IMS and DB2 recovery from separate SLBs and logs (one-time setup)

Primary site activities

The coordinated IMS and DB2 DR (separate SLBs with log apply) demonstration has a few one-time setup steps for the IMS Recovery Expert and DB2 Recovery Expert products, as shown in Figure 20. The following steps are performed:

  1. Register IMS and DB2 systems
  2. Analyze the IMS and DB2 configuration
  3. Define the system-backup profile for IMS and DB2
  4. Define the DR profile for IMS and DB2

The steps to register the IMS and DB2 systems are done in both IMS Recovery Expert and DB2 Recovery Expert.

Figure 20. IMS and DB2 one-time setup (primary site activity)
Image shows IMS and DB2 one-time setup

With this coordinated IMS and DB2 DR solution, the SLBs are created and treated independently. In this respect, it is necessary to create separate system backup and DR profiles for IMS and DB2. The IMS Recovery Expert product creates the profiles for IMS, and the DB2 Recovery Expert product creates the profiles for DB2.

The first step for DB2 is to create the system backup profile, which is done with option 1 from the main ISPF menu. In this step, the user specifies the backup technology to be used (FlashCopy, for example) and whether target volumes should be automatically mapped from a pool of volumes or manually specified by the user. This is shown in Figure 21.

Figure 21. DB2 system backup profile (primary site activity)
Screen cap shows backup profile display

Defining the system backup profile also includes identifying the target pool and the offload options, including whether the volumes are to be copied to tape, compressed, or encrypted. The JCL to validate and complete this setup is built and submitted as shown in Figure 22. In our demonstration, this JCL job is called DB2SETUP.

Figure 22. DB2 system backup profile job (primary site activity)
Screen cap shows build backup job

After the system profile is created, the JCL to create the SLB used in the runtime environment is built as shown in Figure 23. The JCL built will also offload the SLB using the information specified in the backup profile, and it will also back up the Recovery Expert repository after the SLB has been created and offloaded.

Figure 23. DB2 job to create the DB2 SLB (primary site activity)
Image shows IMS and DB2 one-time setup (primary)

The next step is to create the DR profile. In this case, we are creating a DR profile that will be coordinated between IMS and DB2, as shown in Figure 24.

Figure 24. DB2 DR profile (primary site activity)
Image shows DR profile display

DB2 Recovery Expert is notified that this is a coordinated IMS and DB2 DR solution by listing the IMS SSID in the external subsystem field, as shown in Figure 25.

Figure 25. IMS SSID in external subsystem field in DB2 DR profile (primary site activity)
Screen cap shows update DR profile

The final DB2 one-time setup step is to build the job that is run after each SLB is created for DB2 and after each DB2 log data set is archived. In our demonstration, the job we generate is called DRECOVER. When executed at the production system, this job will collect information about the archived log and SLB so it can be coordinated with an IMS log at the remote site to provide a specific PITR that is consistent between IMS and DB2. When executed, the DRECOVER job will also generate the jobs to restore and recover the DB2 environment at the remote site into a PDS. The recovery jobs generated will have a job name of DREMOTE and are built each time the DRECOVER job is executed.

The onetime steps for IMS Recovery Expert are almost identical to the DB2 Recovery Expert steps. However, when the DR profile is created, the DB2 SSID is put into the external subsystem field as shown in Figure 26.

Figure 26. DB2 SSID in external subsystem field in IMS DR profile (primary site activity)
Screen cap shows update DR profile

Coordinated IMS and DB2 disaster recovery (separate SLBs with log apply, runtime)

Coordinated IMS and DB2 recovery from separate SLBs and logs (primary site)

Primary site activities

The coordinated IMS and DB2 DR (separate SLBs with log apply) demonstration shows how separate SLBs can be created for IMS and DB2 production volumes, and used together with archived log data sets to reduce the amount of data loss in the event of a disaster. In this demo, there is an SLB created for IMS using features of the IMS Recovery Expert and an SLB created for DB2 using features of the DB2 Recovery Expert product. When each SLB is created, the IMS or DB2 volumes are the same as those mapped during the one-time setup. It is always possible to add new volumes or for them to be detected automatically when an SLB is created. This was demonstrated in the combined SLB demonstration and shown in Figure 12.

The primary difference between the two coordinated IMS and DB2 DR approaches (combined SLB and separate SLB) is that the archived log data sets are also included in the separate SLB disaster recovery solution. In our demonstration, the IRECOVER job is run after the SLB is created or a log data set is archived for IMS. Similarly, the DRECOVER job is run after the SLB is created or log data set is archived for DB2. These two jobs build the DREMOTE and IREMOTE recovery jobs and place them in the remote PDS data set to be transmitted to the remote site. This is shown in Figure 27 and Figure 28.

Figure 27. IMS Job (IRECOVER) to create recover jobs in remote PDS data set (primary site activity)
Image shows IMS IRECOVER job (primary)
Figure 28. DB2 job (DRECOVER) to create recover jobs in remote PDS data set (primary site activity)
DB2 DRECOVER job (primary)

The key to the coordinated IMS and DB2 DR solution using separate SLBs and archived log data sets is the ability for IMS Recovery Expert and DB2 Recovery Expert to identify a point on the log data sets that is consistent for both IMS and DB2. The last log of each product is identified, and the earlier of the two end times is taken as the coordinated recovery time. For our demonstration, the last DB2 log (PDBISC.E9B1DR.D11155.T1503019.A0000141) was archived at 19:03:01.77. The last IMS log (IMSA3LOG.IAA3.SLDSP.G4689V00) was archived at 19:03:49.6. Therefore, the timestamp selected was 19:03:01.77. This is shown in Figure 29.

Figure 29. Consistent timestamp for coordinated IMS and DB2 disaster recovery (primary site activity)
Image shows IMS and DB2 recovery timestamp (primary)

In our demonstration, we have two BMPs running that are both updating IMS and DB2 databases in the same unit of recovery (UOR). At 19:03:01.77, the last committed update in IMS2DB2 was (LSTNAME03580), which occurred at 19:03:01.704437. The last committed update for IMS2DB3 was (LSTNAME00110), which occurred at 19:02:25.472700. These important timestamps and committed records are shown in Figure 30. If a PITR occurred to 19:03:01.704437 which is consistent between IMS and DB2, the last update in IMS2DB2 should be (LSTNAME03580), and (LSTNAME00110) in IMS2DB3. These updates will be confirmed later in this demonstration.

Figure 30. Key timestamps for IMS and DB2 (primary site activity)
Image shows IMS and DB2 key timestamps (primary)

Coordinated IMS and DB2 DR (separate SLBs with log apply, runtime) (remote site)

Remote site activities

At the remote site, the DR PDS data set is restored, and there are several jobs that need to be executed to restore IMS and DB2 databases using PITR. These steps are shown in Figure 31.

Figure 31. IMS and DB2 recovery steps (remote site activity)
Image shows IMS and DB2 recovery steps (remote)

The first step is to identify the timestamp for PITR recovery. In our demonstration, either the E9A1#CDR and IAA3#CDR jobs can be run to find the correct timestamp. These jobs were created at the production site by the IRECOVER and DRECOVER jobs after an SLB was created or a log was archived. When the DB2 job (E9A1#CDR) is run, it shows the DB2 timestamps first and identifies 20111155 190301.779488 as the correct timestamp for coordinated recovery. This is shown in Figure 32. When the IMS job (IAA3#CDR) is run, it shows the IMS timestamps first and identifies 20111155 190301.779488 as the correct timestamp for coordinated recovery. This is shown in Figure 33.

Figure 32. IMS and DB2 consistent timestamp selection (remote site activity)
Image shows IMS and DB2 identify timestamp (remote)
Figure 33. IMS and DB2 consistent timestamp selection (remote site activity)
Image shows IMS and DB2 identify timestamp (remote)

The next step for DB2 is to restore the DB2 Recovery Expert repository and the SLB as shown in Figure 34. The DB2 Conditional Restart Record is updated with the coordinated timestamp selected and DB2 is started. In IMS, the IMS Recovery Expert repository is recreated and the SLB is restored. The DBRC RECON data set is also restored, having already been conditioned for recovery purposes. IMS Recovery Expert invokes IMS Database Recovery Facility (DRF) for a PITR recovery using the selected timestamp as shown in Figure 35.

Figure 34. DB2 Recovery Expert SLB Restore Output Report (remote site activity)
Image shows DB2 SLB restore (remote)
Figure 35. IMS Database Recovery Facility (DRF) PITR Recovery Output Report (remote site activity)
Image shows IMS DRF PITR recovery (remote)

Once the recoveries are done to the selected timestamp that is consistent between IMS and DB2, and IMS and DB2 are restarted, the database records are displayed. The last committed update for IMS2DB2 is (LSTNAME03580) and is (LSTNAME00110) for IMS2DB3 as shown in Figure 36.

Figure 36. IMS and DB2 databases after PITR recovery (remote site activity)
Image shows IMS and DB2 Database after PITR recovery (remote)

Conclusion

This tutorial showed how a coordinated IMS and DB2 disaster recovery solution could be created using the IMS Tools product, IMS Recovery Expert, together with the DB2 Tools product, DB2 Recovery Expert. Each product uses the system-level backup (SLB) as a recovery resource.

There were two DR solutions shown. The first used a combined SLB for IMS and DB2 volumes for recovery without applying any log updates. The second used separate SLBs for IMS and DB2, and applied log updates from IMS and DB2 to the databases in each. A restart of IMS and DB2 was required for the first solution, while point-in-time-recovery was required for the IMS databases in the second solution.


Downloads

DescriptionNameSize
IMS Disaster Recovery Demonstrations1IMS_Backup_and_Recovery_Demos.zip3330KB
Download Instructions for Demonstrations2IMSBackupandRecoveryDemoInstructions.pdf768KB

Notes

  1. This download is the same for all parts of this article/tutorial series.
  2. This PDF file is the same for all parts of this series. If you have downloaded it for a previous article or tutorial in the series, there is no need to download it again.

Resources

Learn

Get products and technologies

  • Build your next development project with IBM trial software, available for download directly from developerWorks.
  • Now you can use DB2 for free. Download DB2 Express-C, a no-charge version of DB2 Express Edition for the community that offers the same core data features as DB2 Express Edition and provides a solid base to build and deploy applications.

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Information management on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Information Management
ArticleID=812576
ArticleTitle=Exploring IMS disaster recovery solutions, Part 4: Coordinated IMS and DB2 solutions
publish-date=05032012