A database can become unusable because of hardware or software failure (or both), and the different failure situations may require different recovery actions. You should have a strategy in place to protect your database against the possibility of these failure situations. When designing a strategy, you should also rehearse it. This will allow you to detect any shortcomings in the plan, and to avoid problems if you have to recover the database.
This chapter discusses the different recovery methods that can be used in the event there is a problem involving the database. Also discussed are considerations and decisions that will assist in determining the recovery method best suited to your business environment. Each recovery method is described along with the associated concepts, and the commands provided with the product to support these methods.
The following are major topics within this chapter:
If you have tables that contain DATALINK columns, also refer to "DB2 File Manager Considerations".
One type of problem that requires point-in-time roll-forward recovery is the corruption of data that is caused by errant logic or incorrect input in an application. You can use roll-forward recovery to recover the database to a point in time that is close to when the application began working with the database. Or, you can attempt to back out the effects of the application on the database by executing the transactions in reverse. You must exercise caution if you decide to follow the second approach. This chapter does not provide further information about application errors.