DB2 Server for VSE & VM: Data Restore Guide

Changing Your Recovery Strategies

This section reviews some common recovery strategies and makes recommendations for new strategies to exploit new Data Restore functions.

Prior to SQL/DS Release 3.5, many users took user database archives because external tools provided better performance. To also be able to recover data at the table level, many users also performed dbspace and table unloads for critical data.

Now that the Data Restore feature is available and the database manager archive has been enhanced, there are some alternatives to be considered.

If you currently take online database archives:

If you are using the DB2 ARCHIVE online, there is no need to alter your recovery strategy. You get the additional advantage of the performance enhancement to the archive process.

If you used to make additional backups using UNLOAD, you can omit this. Data Restore RELOAD allows you to RELOAD tables from the archive online, and additionally offers you the ability to apply forward log recovery to the reloaded tables. You can choose to use either the implicit (in Data Restore RELOAD) or explicit (in TRANSLATE) translate process. You can also use the Data Restore RESTORE command to recover a storage pool.

You just have to install the Data Restore feature and become familiar with the Data Restore RELOAD and RESTORE, and optionally TRANSLATE process, as well as LISTLOG and APPLYLOG. See Figure 2.

Figure 2. Migration from Online DB2 Archive

If you currently take database manager archives on shutdown:

If DB2 archive was used offline with SQLEND ARCHIVE, you can keep this archive option and consider the TRANSLATE, or you can recover using Data Restore BACKUP to omit the TRANSLATE. You can also switch to online archive, because it now takes less time. This might take a little bit more time than offline, if there are any users running concurrently with the archive, but there is the advantage of keeping the database online. See Figure 3 Choices A, B and C.

If you used to make additional backups in form of UNLOAD, you can omit this. Data Restore RELOAD allows you to RELOAD tables from the archive online, and additionally offers you the ability to apply forward log recovery to the reloaded tables. You can choose to use either the implicit (in Data Restore RELOAD) or explicit (in TRANSLATE) translate process.

You just have to install the Data Restore feature and become familiar with the Data Restore RELOAD and RESTORE, and BACKUP or TRANSLATE process, as well as LISTLOG and APPLYLOG.

Figure 3. Migration from Offline DB2 Archive

If you currently take user database archives:

Most of the user archive tools were better performers than the DB2 archive. In addition to this, unload of selected dbspaces was used to have the possibility for individual restore. (See Figure 4 "Current Strategy".) If all or a major part of the dbspaces would be unloaded, this could take some time and resources, although the unload could run when the database was online.

Now you have two choices:

1. Migrate to Data Restore feature BACKUP, which is also performed with the database offline. This might take some more time than your usual archive, (see Figure 4 "Choice A"), but has major advantages:
   • No maintenance of the input definitions (to run the user archives) is required. The Data Restore feature just needs access to the production disk (default 195) in VM, or to the database identification job, containing the DLBL statements for the extents in VSE.
   • All storage pools are available for individual restore.
   • All tables are available for individual restore. Thus, additional UNLOAD of selected or all data can be omitted.
   • Reload tables with forward recovery is possible.
2. If the availability of the database is a major requirement, changing your recovery strategy to online DB2 ARCHIVE could be considered. The possible disadvantage is the additional translate process, which can be performed at any time. (See Figure 4 "Choice B".)

For recovery to online DB2 archive, the procedures would have to be changed, so the operator command should be executed instead of ending the database, running your user archive, and later possibly doing additional unloads. If you run with LOGMODE=A, you might want to additionally take offline archives at longer intervals for disaster recovery.

If Data Restore feature BACKUP is selected as an alternative for your archive, then there would be no change in the process of ending your database. You just replace your user archive procedure by starting the Data Restore BACKUP.

In both cases, additionally having the database definition files (to be copied only after changes of the database layout) should be considered, as described in Recover from System Failure, to have the chance to restore and run the database on another system. You might want to check whether these files have been included in your current user archives or not, and whether restore on another system is reflected in your recovery strategy.

You can improve the recovery even further by taking a copy of the log history to tape after each log archive, as described in ***.

Figure 4. Migration from User Archive