Resetting table space status

In most cases, resetting the COPY-pending restriction by taking a full image copy is preferable to using REPAIR. This is because RECOVER cannot be executed successfully until an image copy has been made.

Resetting the RECOVER-pending status by running RECOVER or LOAD is preferable to using REPAIR. This is because RECOVER uses DB2®-controlled recovery information, whereas REPAIR SET TABLESPACE or INDEX resets the RECOVER-pending status without considering the recoverability of the table space. Recoverability issues include the availability of image copies, of rows in SYSIBM.SYSCOPY, and of log data sets.

Verifying and possibly correcting referential integrity constraints by running CHECK DATA are recommended. CHECK DATA performs a complete check of all referential integrity constraints of the table space set, whereas with REPAIR, you are responsible for checking all the referential integrity constraints violations.

To reset the CHECK-pending status for a LOB table space:

  1. Run the CHECK DATA utility again with the AUXERROR INVALIDATE keywords specified.
  2. Update the invalid LOBs.

To reset the auxiliary warning (AUXW) status for a LOB table space:

  1. Update or correct the invalid LOB columns, then
  2. Run the CHECK LOB utility with the AUXERROR INVALIDATE option if invalid LOB columns were corrected.