Actions to take to aid in successful recovery of inconsistent data

You need to take certain steps to prepare for the successful recovery of inconsistent data when you set up the database.

• During the installation of, or migration to, Db2 13, make a full image copy of the Db2 directory and catalog by using installation job DSNTIJIC.

  If you did not take this copy during installation or migration, use the COPY utility to make a full image copy of the Db2 catalog and directory. If you do not take such a copy and later find inconsistent data in the Db2 catalog or directory, you cannot use the RECOVER utility to resolve the problem.

  This action is recommended even if you take system-level backups.

• Periodically make an image copy of the catalog, directory, and user databases.

  These copies minimize the time that the RECOVER utility requires to recover the data. This action also increases the probability that the necessary archive log data sets are available when you need them. Keep two copies of each level of image copy data set. Having a second copy reduces the risk in case one image copy data set is lost or damaged.

  This action is recommended even if you take system-level backups.

• Use dual logging for your active log, archive log, and bootstrap data sets.

  Dual logging increases the probability that you can recover from unexpected problems. Dual logging is especially useful in resolving data inconsistency problems.

• Use redirected recovery, the RECOVER utility with the FROM option, to recover production data into a test object to a point in time or to the current state with transactional consistency without affecting availability of the production object.

  The data recovered in the test object can be used for analysis, review, and validation. SQL SELECTS can be used to compare the data in the test object to the data in the production object. SQL INSERT, UPDATE, or DELETE can be used to fix the data in the production object. This method of recovery can also be used to test and validate that recovery on the production object will be successful.

• Before you use RECOVER, rename your data sets.
  Restriction: Do not rename your data sets if you take system-level backups.

  If the image copy or log data sets are damaged, you can compound the problem by using the RECOVER utility. Therefore, before you use RECOVER, rename your data sets by using one of the following methods:

  • Rename the data sets that contain the page sets that you want to recover.
  • Copy your data sets by using DSN1COPY.
  • For user-defined data sets, use access method services to define a new data set with the original name.

  The RECOVER utility applies log records to the new data set with the old name. Then, if a problem occurs during RECOVER utility processing, you have a copy (under a different name) of the data set that you want to recover.

• Keep earlier copies of your data.

  If you make an image copy or system-level backup of a page set that contains inconsistent data, RECOVER cannot resolve the data inconsistency problem. However, you can use RECOVER TOCOPY or TOLOGPOINT to resolve the inconsistency if you have an older image copy or system-level backup that was taken before the problem occurred. You can also resolve the inconsistency problem by using the RESTOREBEFORE recovery option to avoid using the most recent image copy.

• Maintain consistency between related objects.

  A referential structure is a set of tables, including indexes and their relationships. It includes at least one table, and for every table in the set, all of the relationships in which the table participates and all the tables to which it is related. To help maintain referential consistency, keep the number of table spaces in a table space set to a minimum. Also, avoid tables of different referential structures in the same table space. The TABLESPACESET option of the REPORT utility reports all members of a table space set that are defined by referential constraints.

  A referential structure must be kept consistent for point-in-time recovery. Use the QUIESCE utility to establish a point of consistency for a table space set. Later the table space set can be recovered to this point of consistency without introducing referential constraint violations.

  A base table space must be kept consistent with its associated LOB or XML table spaces for point-in-time recovery. Use the TABLESPACESET option of the REPORT utility to identify related objects. Related objects can include referentially related objects and auxiliary LOB or XML table spaces and their indexes. Run CHECK INDEX to validate the consistency of indexes with their associated table data. Run CHECK DATA to validate the consistency of base table space data with LOB, XML, and referentially related table spaces. If LOB columns exist, run CHECK LOB on any related LOB table spaces to validate the integrity of each LOB table space within itself.