Recovery of catalog and directory tables

Recovering catalog and directory tables to a prior point in time is strongly discouraged for several reasons.

• You must recover all table spaces that are associated with the catalog tables that you recover to the same point in time. For example, if you recover any table space in the Db2 catalog (DSNDB06) and directory (DSNDB01), all table spaces (except SYSUTILX) must be recovered.

  The catalog and directory contain definitions of all databases. When databases DSNDB01 and DSNDB06 are restored to a prior point, information about later definitions, authorizations, binds, and recoveries is lost. If you restore the catalog and directory, you might need to restore user databases; if you restore user databases, you might need to restore the catalog and directory.

• You might create catalog definitions that are inconsistent with your data. These catalog and data inconsistencies are usually the result of one of the following actions:
  • A catalog table space was restored.
  • SYSSEQ and SYSSEQ2 were recovered to a prior point in time.
  • The definition of a table, table space, index, or index space was changed after the data was last backed up.
• You can cause problems for user table spaces or index spaces that have been reorganized with SHRLEVEL REFERENCE or SHRLEVEL CHANGE.
• You can cause a populated VSAM data set that was defined with DEFINE NO option to revert back to the undefined state. To avoid errors, you must delete the existing VSAM data sets before the table space or index can be accessed.