There are several circumstances in which you will need to ensure that adequate protection for your data is in place. In some cases, DB2 takes care of this for you; other cases require careful consideration and planning on your part. The following list outlines situations that require data recovery:
The operating system crashes, due to either a software or hardware problem, or the system as a whole goes down unexpectedly due to some external power problem before all the changes that are part of a unit of work have been completed and committed.
An application is running but the database manager ends abnormally before the application can either commit or roll back its changes. Roll back refers to restoring changes to the state they were in when they were last committed in the database.
A hardware failure (for example, head crash, bad sector) occurs on a disk running your DB2 database.
Errant program logic or invalid data entry leads to invalid data in the database that DB2 cannot prevent.
A wide range of non-trivial damage to more than just a single component of your machine. The system running DB2 becomes partially or completely destroyed, or the facility at which your systems are located suffers damage that impacts your operation.
As a database administrator, you need to evaluate the impact that each of the above would have on your business and implement a backup plan accordingly. The Backup Database SmartGuide (described in "Step 5. Backing Up a Database for the First Time") helps you with this.
DB2 handles system crashes and transaction failures automatically. It uses the active logs to recover from these two types of failures, so you should not need to make use of your backup for these two types of failures. Further details on logging facilities are provided in "About the Logs that DB2 Keeps".
Media failure is a typical cause of lost data requiring recovery. The options for protecting against this type of failure include database backups.
Point-in-time recovery may be able to assist you in minimizing damage caused by application logic errors.
Disaster recovery is a broad topic. At a minimum, data must be backed up and stored at a location not affected by the damage to the primary site. Beyond that, required procedures that are unique to each case are not discussed here.