Recovering damaged table spaces

A damaged table space has one or more containers that cannot be accessed. This is often caused by media problems that are either permanent (for example, a bad disk), or temporary (for example, an offline disk, or an unmounted file system).

If the damaged table space is the system catalog table space, the database cannot be restarted. If the container problems cannot be fixed leaving the original data intact, the only available options are:

  • To restore the database
  • To restore the catalog table space.
    Note:
    1. Table space restore is only valid for recoverable databases, because the database must be rolled forward.
    2. If you restore the catalog table space, you must perform a rollforward operation to the end of logs.

If the damaged table space is not the system catalog table space, Db2® attempts to make as much of the database available as possible.

If the damaged table space is the only temporary table space, you should create a new temporary table space as soon as a connection to the database can be made. Once created, the new temporary table space can be used, and normal database operations requiring a temporary table space can resume. You can, if you want, drop the offline temporary table space. There are special considerations for table reorganization using a system temporary table space:

  • If the database or the database manager configuration parameter indexrec is set to RESTART, all invalid indexes must be rebuilt during database activation; this includes indexes from a reorganization that crashed during the build phase.
  • If there are incomplete reorganization requests in a damaged temporary table space, you might have to set the indexrec configuration parameter to ACCESS to avoid restart failures.