Auxiliary CHECK-pending status

When auxiliary CHECK-pending (ACHKP) restrictive status is set on a base table space, that table space is unavailable for processing by SQL.

The following situations are examples of when ACHKP status is set on a base table space:

  • The CHECK DATA utility is run with the AUXERROR REPORT option, and at least one LOB column error is detected but not invalidated.
  • A base table space and its LOB table spaces are recovered to the current point in time in the same RECOVER utility invocation, and both the base table space and the LOB table spaces are defined with the NOT LOGGED attribute.

ACHKP status is set on an XML table space when CHECK DATA is run with the XMLERROR REPORT option, and the utility finds an error in an XML table space, the corresponding base table space, or an index space for the node ID.

To reset ACHKP status, take the actions that are described in the following table.

Table 1. Resetting auxiliary CHECK-pending status
Status Abbreviation Object affected Corrective action
Auxiliary CHECK-pending ACHKP Base table space
  1. Update or delete invalid LOBs and XML objects by using SQL.
  2. Run the CHECK DATA utility with the appropriate SCOPE option to verify the validity of LOBs and XML objects and reset ACHKP status.

If a table space is in both REORG-pending status and auxiliary CHECK-pending status (or CHECK-pending status), run the REORG TABLESPACE utility first and then run CHECK DATA to reset the respective states.

You can use the REPAIR utility to reset the ACHKP status, but use caution, as it does not correct the underlying problem that caused the restrictive state to be set. If you do run REPAIR, run CHECK DATA afterward.