In this chapter we describe some database management systems with different requirements to help you define possible strategies for your database environment.
This strategy looks as follows:
User archive + unloads > failure - restore
restore is either of:
This strategy has been widespread, for example using DDR because it used to be quicker than DB2 ARCHIVE until SQL/DS V3R5. In addition to the user archive, the important tables or even all tables were unloaded to be able to fix smaller problems quickly.
You should make sure that the database definition files and the log file are included in your user archive.
With the enhanced capabilities of SQL/DS V3R5 and the availability of the Data Restore feature, it might be advantageous to change your recover strategy to one of the following.
This strategy looks as follows:
Online DB2 ARCHIVE - Data Restore TRANSLATE > failure - restore
restore is either of:
Because of the availability of the database, the DB2 archive is always followed by a translate process, keeping a copy of the work files. This has been chosen because the reload of individual tables with forward recovery is considered to apply and must perform quickly.
If you need to recover one or more storage pools, Data Restore RESTORE of a storage pool is the best choice.
When individual tables need to be recovered, Data Restore RELOAD is the best alternative.
For a complete restore you can choose between a restore from DB2 and Data Restore RESTORE.
Complete log recovery is possible in both cases, RELOAD of a table and RESTORE of the whole database, and you will be prompted for the log archives (if any) according to the information that is available in the log history.
With a lower frequency, any kind of offline archive is made for disaster recovery. For the same purpose, a copy of the database definition files is kept with the archives.
This strategy looks as follows:
Online DB2 ARCHIVE > failure - restore
restore is either of:
Because reload with forward recovery is not requested with ultimate performance, the translate process has been chosen to be bypassed.
Similarly, it was decided for the recovery of a storage pool:
When a table needs to be recovered, Data Restore RELOAD can be run from the DB2 archive. The reload of tables is slower, because the tapes are read twice, but this time is accepted because reload is not often requested. A lot of time and effort is saved in comparison to the scenario where a Data Restore TRANSLATE is executed on each archive.
For the case of a complete restore, DB2 restore can be applied, which is equivalent to the slower alternative of first running a Data Restore TRANSLATE and then Data Restore RESTORE.
As in the previous scenario, complete log recovery is possible in both cases, RELOAD of a table and restore of the whole database, and you will be prompted for the log archives (if any), according to the information that is available in the log history.
With a lower frequency, any kind of offline archive is made for disaster recovery. For the same purpose, a copy of the database definition files is kept with the archives.
This strategy looks as follows:
Data Restore BACKUP > failure - Data Restore RESTORE
restore is either of:
There are three reasons why this strategy can be chosen:
If you need to recover one or more storage pools, Data Restore RESTORE of a storage pool is the best alternative.
When individual tables need to be recovered, Data Restore RELOAD is the choice.
For a complete restore you use Data Restore RESTORE.
Complete log recovery is possible in both cases, RELOAD of a table and RESTORE of the whole database, and you will be prompted for the log archives (if any), according to the information that is available in the log history.
For disaster recovery, a copy of the database definition files is kept with the archive.
This strategy looks as follows:
Data Restore BACKUP FULL/INCREMENTAL > failure - Data Restore RESTORE
restore is either of:
There are four reasons why this strategy can be chosen:
If Data Restore functions are processing an INCREMENTAL archive file, to reload individual tables or restore a storage pool or complete database, the associated FULL archive will be accessed while processing.