Recovery

Lack of availability may affect your operations, income  and reputation. It is difficult to be prepared for every  possible recovery scenario. There are too many. The DBA must have good skills and tools to easily and quickly help generating recovery jobs for each specific scenario. TUC allows generating recovery jobs using a friendly online  dialog, to recover an entire disk, an entire database, recovery to last backup or to a point in time. In addition TUC allows generating recovery jobs for expected scenarios and executes these recovery jobs by priority, for example,  as part of a disaster recovery scenario. Using priorities allow the recovery of your most critical tables first. TUC recovers indexes instead of rebuilding indexes whenever possible. Auxiliary, dependent or related objects can be included automatically. TUC speeds up the recovery  process using parallelism, which allows scanning the log once for a list of objects.

 

Displaying Objects

TUC allows you to display lists of databases, tablespaces, tables, indexes,  datasets and events. From the displayed list you can use a wide range of line commands including recovery jobs and log analysis jobs. The ease of use allows you to quickly generate the desired JCL without additional manual effort.

 

Recovery to Point in Time

TUC uses log analysis to detect logical units of recovery and quiet points, periods of no activity against a group of objects that can be used as points of consistency. TUC allows the user to select a valid point of consistency for recovery and generate recovery jobs. If you avoid taking QUIESCE, TUC can use log analysis to detect a quiet point when requesting to recover objects to a point in time that is not known as a point of consistency for a group of objects. If data was corrupted by an application program, TUC allows the user to display unit of recovery and generate RECOVER statements to recover the tables to a consistent point in time before the data was corrupted.

 

 

Mass Recovery

Disaster recovery scenarios may create the need to recover a high number of objects. The recommendation is to recover many objects in a single recover statement to allow DB2 to pass the log records once for all included objects. Multiple log reads can significantly slow down recovery, especially if the log records are no longer available in the active logs and archive logs must be accessed. It is a good practice to generate the recover jobs and have them available in a library so you do not have to spend too much time in kick starting the recover process. In addition, it is a good idea to set higher priorities for your most critical databases, to allow you to resume business activity as soon as your strategic applications become available.

 

Ensuring Recoverability

The QUIESCE utility is often used to set a point of consistency for recovery. However, QUIESCE does not ensures recoverability because you cannot recover if the last full image copy is lost, logs are lost or a non recoverable event occurred since the last backup. To ensure that points of consistency are recoverable, you need to look for non recoverable events. Non recoverable event is any event manipulating the data without recording the changes in the DB2 log. This can happen with DB2 utilities running with the LOG NO option such as REORG, LOAD and CHECK. It is a good idea to take an image copy after running these utilities or before QUIESCE. If the changes are not logged, the RECOVER utility cannot recover the data to current or to a point in time after the event.

The availability of the image copy datasets is also critical. Image copies can be deleted accidently or when expired. Image copies are also required for new populated tables that have not been copied yet. Recovery fails if the image copy datasets were deleted and are no longer available. It is a good practice to check for the availability of the last full image copy prior to QUIESCE and take a new image copy if the last copy is missing.

 

Recovering Indexes

If you recover to a point in time, you must also rebuild the associated indexes. Rebuilding large indexes could delay availability. It is recommended to backup large indexes, because recovering indexes with backups can significantly speed up the recovery process.

 

Recovering Volumes

Disk failures are no longer a big concern ever since the introduction of mirroring technologies. However, if it is needed to recover all the DB2 objects on a specific volume, TUC can easily identify the objects that were allocated on the failing volumes and generate recover jobs to restore data and rebuild indexes.

Go Back Up