This chapter is from the book
This chapter is from the book
This chapter is from the book
Database Recovery Concepts
Over time, a database can encounter any number of problems, including power interruptions, storage media failure, and application abends. All of these can result in database failure and each failure scenario requires a different recovery action.
The concept of backing up a database is the same as that of backing up any other set of data files: you make a copy of the data and store it on a different medium where it can be accessed in the event the original becomes damaged or destroyed. The simplest way to backup a database is to shut it down to ensure that no further transactions are processed, and then back it up using the BACKUP utility provided with DB2 UDB. Once the backup image has been made, you can rebuild the database if for some reason it becomes damaged or corrupted.
The process of rebuilding a database is known as recovery and with DB2 UDB, three types of recovery are available. They are:
-
Crash recovery
-
Version recovery
-
Roll-forward recovery
Crash Recovery
When an event or condition occurs that causes a database and/or the DB2 Database Manager to end abnormally, one or more transaction failures may result. Conditions that can cause transaction failure include:
-
A power failure at the workstation where the DB2 Database Manager is running.
-
A serious operating system error.
-
A hardware failure such as memory corruption, disk failure, CPU failure, or network failure.
-
An application failure.
When a transaction failure takes place, all work done by partially completed transactions that was still in memory is lost. And because some of that work may not have been externalized to the database, the database is left in an inconsistent state (and therefore is unusable). Crash recovery is the process that returns such a database to a consistent and usable state. Crash recovery is performed by using information stored in the transaction log files to roll back all incomplete transactions found and complete any committed transactions that were still in memory (but had not yet been externalized to the database) when the transaction failure occurred. Once a database is returned to a consistent and usable state, it has attained what is known as a "point of consistency."
Version Recovery
Version recovery is the process that returns a database to the state it was in at the time a backup image was made. Version recovery is performed by replacing the current version of a database with a previous version, using an image that was created with a backup operation; the entire database is rebuilt using a backup image created earlier. Unfortunately, when a version recovery is performed, all changes that have been made to the database since the backup image was created will be lost. Version recovery can be used to restore an entire database or it can be used to restore individual tablespaces—provided individual tablespace backup images exist.
Roll-Forward Recovery
Roll-forward recovery takes version recovery one step farther by replacing a database or individual tablespaces with a backup image and replaying information stored in transaction log files to return the database/tablespaces to the state they were in at an exact point in time. In order to perform a roll-forward recovery operation, you must have archival logging enabled, you must have a full backup image of the database available, and you must have access to all archived log files (or at least the ones you want to use for recovery) that have been created since the backup image was made. Like version recovery, roll-forward recovery can be applied to an entire database or to individual tablespaces.
Recoverable and Non-recoverable Databases
Although any DB2 UDB database can be recovered from transaction log files (crash recovery) or a backup image (version recovery), whether or not a database is considered recoverable is determined by the values of the database's logretain and userexit configuration parameters; a database is recoverable if the logretain parameter is set to RECOVERY and/or the userexit parameter is set to YES. (When both of these configuration parameters are set to NO, which is the default, circular logging is used and the database is considered non-recoverable.) A database is considered recoverable when crash recovery, version recovery, and roll-forward recovery is possible. A database is considered non-recoverable if roll-forward recovery is not supported. Other differences between recoverable and non-recoverable databases are shown in Table 7-1.
Table 7-1. Differences between Recoverable and Non-recoverable Databases
|
Recoverable Database |
Non-recoverable Database |
|---|---|
|
Archive logging is used. |
Circular logging is used. |
|
The database can be backed up at any time, regardless of whether or not applications are connected to it and transactions are in progress. |
The database can only be backed up when all connections to it have been terminated. |
|
The entire database can be backed up or individual tablespaces can be backed up. Tablespaces can also be restored independently. |
The entire database must be backed up; tablespace level backups are not supported. |
|
A damaged database can be returned to the state it was in at any point in time; crash recovery, version recovery, and roll-forward recovery are supported. |
A damaged database can only be returned to the state it was in at the time the last backup image was taken; only crash recovery and version recovery are supported. |
The decision of whether a database should be recoverable or non-recoverable is based on several factors:
-
If a database is used to support read-only operations, it can be non-recoverable; since no transactions will be logged, roll-forward recovery is not necessary.
-
If relatively few changes will be made to a database and if all changes made can be easily recreated, it may be desirable to leave the database non-recoverable.
-
If a large amount of changes will be made to a database or if it would be difficult and time-consuming to recreate all changes made, a recoverable database should be used.
Online versus Offline Backup and Recovery
From a backup and recovery perspective, a database is either online or offline. When a database is offline, other applications and users cannot gain access to it; when a database is online, just the opposite is true. Backup and recovery operations can only be performed against a non-recoverable database after that database has been taken offline. Recoverable databases, on the other hand, can be backed up at any time, regardless of whether the database is offline or online. However, in order to restore a recoverable database (using version recovery and roll-forward recovery), the database must be taken offline. (It is important to note that a recoverable database only has to be taken offline if the entire database is to be restored; individual tablespaces can be restored while the database is online.)
When an online backup operation is performed, roll-forward recovery ensures that all changes made while the backup image is being made are captured and can be recreated with a roll-forward recovery operation. Furthermore, online backup operations can be performed against individual tablespaces as well as entire databases. And, unlike when full database version recovery operations are performed, tablespace version recovery operations and tablespace roll-forward recovery operations can be performed while a database remains online. When a tablespace is backed up online, it remains available for use and all simultaneous modifications to the data stored in that tablespace are recorded in the transaction log files. However, when an online restore or online roll-forward recovery operation is performed against a tablespace, the tablespace itself is not available for use until the operation has completed.
Incremental Backup and Recovery
As the size of a database grows, the time and hardware needed to backup and recover the databases also grows substantially. Furthermore, creating full database and tablespace backup images is not always the best approach when dealing with large databases, because the storage requirements for multiple copies of such databases can be enormous. A better alternative is to create one full backup image and several incremental backup images as changes are made. An incremental backup is a backup image that only contains pages that have been updated since the previous backup image was made. Along with updated data and index pages, each incremental backup image also contains all of the initial database meta-data (such as database configuration, tablespace definitions, recovery history file, etc.) that is normally found in full backup images.
Two types of incremental backup images are supported: incremental and delta. An incremental backup image is a copy of all database data that has changed since the most recent, successful, full backup operation has been performed. An incremental backup image is also known as a cumulative backup image, because a series of incremental backups taken over a period of time will have the contents of the previous incremental backup image. The predecessor of an incremental backup image is always the most recent successful full backup of the same object.
A delta backup image is a copy of all database data that has changed since the last successful backup (full, incremental, or delta) of the object in question. A delta backup image is also known as a differential, or noncumulative, backup image; the predecessor of a delta backup image is the most recent successful backup image that contains a copy of each of the objects found in the delta backup image.
The key difference between incremental and delta backup images is their behavior when successive backups are taken of an object that is continually changing over time. Each successive incremental image contains the entire contents of the previous incremental image, plus any data that has changed, or has been added, since the previous full backup image was produced. Delta backup images only contain the pages that have changed since the previous backup image of any type was produced. In either case, database recovery involves restoring the database using the most recent successful full backup image available and applying each incremental backup image produced, in the order in which they were made. (The recovery history file keeps track of which incremental and delta backup images are needed and the order that they were made in.)