The steps required to perform a database backup using the Backup Database SmartGuide are described in "Step 5. Backing Up a Database for the First Time". The SmartGuide helps you make basic protection decisions. Here we describe some aspects of database backup and recovery in more detail. Another type of DB2 backup, a table space backup, is covered in the Administration Guide.
The concept of a database backup is the same as any other data backup: taking a copy of the data and storing it on a different medium in case of failure or damage to the original. The simplest case of a backup requires shutting down the database to ensure that no further transactions occur, and then simply backing it up.
An aspect that is unique to database backups is the need to consider the database logs. If a database needs to be restored to a point beyond the last full, off-line backup, then logs are required to roll the data forward to the point of failure. Rolling data forward refers to the log journal information which is applied against a restored database. Log journals contain the changes made to the database since the last backup. After these journals have been applied, the database will be in the same state as it was prior to the failure. In the case of a machine or site disaster in which the logs are destroyed, the database can only be restored to the point of the last full backup and only if the backup media were stored at a location unaffected by the disaster.
All databases have logs associated with them. These logs keep records of database changes. Some logs, called active logs, prevent a failure (system power, application error) from leaving a database in an inconsistent state. They restore the state of a database to the point before the change. See the Administration Guide for additional information about transaction support.
There are two types of DB2 logging: circular and archive, with each providing a different level of recovery capability. Your choice between these two depends on your business needs with respect to the recovery of your database in the event of a failure.
Circular logging is the default when a new database is created. With this type of logging, only full, off-line backups of the database are valid. As the name suggests, circular logging uses a "ring" of online logs in order to provide recovery from transaction failures and system crashes. The logs are used and retained only to the point of ensuring the integrity of current transactions. Circular logging does not allow you to roll forward a database through prior transactions from the last full backup. Recovery from media failures and disasters is done by restoring from a full, off-line backup. All changes since the last backup are lost. The database must be off-line (inaccessible to users) when a full backup is taken. Since this type of restore recovers your data to the specific point in time of the full backup, it is sometimes called version recovery.
Figure 21 illustrates how the active log uses a ring of log files when circular logging is active.
|
Active logs contain transactions which have not yet been committed or rolled back, or whose changes have not yet been written to disk. Active logs are located in the database log path directory.
Archive logging enables forward recovery using active and archived logs to any point in time before the failure, rather than only to the point in time of a full backup. With archive logging, active logs are retained and become online, archived logs. In addition, archived logs can be moved off-line and still used for roll-forward recovery. Archive logging is activated when either the LOGRETAIN or USEREXIT (or both) parameter is enabled. Once archive logging is activated, a full backup of the database is required. If LOGRETAIN or USEREXIT are turned off, logging reverts to circular, and the online logs are automatically deleted. If it is necessary to back out the changes from an errant application that damaged data, a database can be rolled forward using the logs to any point in time between the full, off-line backup and the last completed transaction.
Figure 22 shows a database using active log files and online archived log files.
 |
With archive logging, it becomes necessary to pay more attention to the handling of the logs and to ensure their safety. The ability to perform roll-forward recovery of your database is dependent on the integrity of the logs. Consideration should be given to backing up log data and to keeping it on disk arrays or mirrored volumes. A suggestion is provided in "Choosing a Backup Strategy". For either type of logging, performance factors such as the location and size of the logs needs to be evaluated for the impact on overall system performance. Finally, in planning for disaster recovery, be sure to remember that log data must be stored off-site, or at least safely away from the disaster, in order to recover your database beyond the point of the last full, off-line backup.
When all changes in the active log are no longer needed for normal processing, the log is closed and becomes an archived log. An archived log is said to be "online" when it is stored in the database log path directory.
You also have the ability to store archived logs in a location other than the database log path directory, by using a user exit program. (See the section on user exits for database recovery in the Administration Guide.) An archived log is said to be "off-line" when it is not stored in the database log path directory.
The interaction among the active log file and offline archived log files is shown in Figure 23.
Figure 23. Offline Archived Logs
 |
The database configuration file contains parameters related to roll-forward recovery. The default parameters do not support this recovery, so if you plan to use it, you need to change some of these defaults. In "Step 5. Backing Up a Database for the First Time" we recommend that you choose archive logging so that the LOGRETAIN parameter is set to Yes, and that you do not make any changes to your database until this point. This means archived logs will be kept in the database log path directory and that the roll-forward recovery method will be used.
To modify the parameters related to roll-forward recovery: