DB2 Recovery

Recovery is how DB2 brings data back after something goes wrong: a disk failure, a program abend in the middle of updates, or an operator error. DB2 recovery is built on two things: image copies and logs.

Why recovery is needed

• Media failure: a disk or tablespace is damaged and the data on it cannot be read.
• Application failure: a program abends after updating half the rows. The half-done work must be undone or completed.
• Human error: wrong data loaded or wrong rows deleted, and you must go back to an earlier point.
• DB2 handles a system crash automatically at restart. Damaged data needs the RECOVER utility run by the DBA or operations.

Types of recovery

• Crash recovery: automatic. When DB2 restarts after a failure, it uses the logs to redo committed work and undo uncommitted work.
• Media recovery: the RECOVER utility restores a tablespace or index from the latest image copy, then applies log changes made after that copy.
• Point-in-time recovery: recovers to a specific moment, for example to the state before a bad batch run, using TOCOPY or TOLOGPOINT options.
• Individual partitions of a partitioned tablespace can be recovered independently, so one bad partition does not stop the rest.

Running the RECOVER utility

• The DBA submits a RECOVER utility job naming the tablespace or index to recover.
• RECOVER finds the newest usable image copy in SYSIBM.SYSCOPY, restores it, then rolls the logs forward to the current point or to your target point.
• Take a fresh image copy after any recovery, because the old copy chain is broken.
• Example JCL:-
  //RECOVER EXEC DSNUPROC,SYSTEM=DB2T //SYSIN DD * RECOVER TABLESPACE DBONE.TSONE /*