Auxiliary warning status
A base table space or LOB table space in auxiliary warning (AUXW) status remains available for processing by SQL even though it contains invalid LOBs.
Db2 can access all rows of a base table space that is in AUXW status. SQL can update the invalid LOB column and delete base table rows, but it cannot retrieve the value of the LOB column. If Db2 attempts to access an invalid LOB column, a -904 SQL code is returned. The AUXW status remains on the base table space even when SQL deletes or updates the last invalid LOB column.
The following situations are examples of when AUXW status is set:
- The CHECK DATA utility is run with the AUXERROR INVALIDATE option, and at least one LOB column has an invalidated LOB.
- CHECK DATA is run with the AUXERROR REPORT option and encounters only invalid LOB columns and no other LOB column errors. In this case, the base table space is set to AUXW status.
- 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. In this case, if updates were made to the LOB table spaces after the recoverable point, AUXW status is set on the LOB table spaces.
- An invalid LOB column is found by the RECOVER utility after the following series of events:
- The LOB table space was defined with the NOT LOGGED attribute.
- The LOB table space was recovered.
- The LOB was updated since the last image copy.
To reset AUXW status, take the actions that are described in the following table.
| Status | Abbreviation | Object affected | Corrective action |
|---|---|---|---|
| Auxiliary warning | AUXW | Base table space |
|
| Auxiliary warning | AUXW | LOB table space |
|