LOBs with DB2 for z/OS: Stronger and Faster

206 LOBs with DB2 for z/OS: Stronger and Faster

6.12 CHECK LOB

The CHECK LOB online utility can be run against a LOB table space to identify any structural

defects in the LOB table space and signal any invalid LOB values. Run CHECK LOB when

you suspect there might be structural defects or when the LOB table space is in the check

pending state (CHKP) or auxiliary warning state (AUXW).

The CHECK LOB utility can only be run on a LOB table space, not on a base table space.

The CHECK LOB utility only accesses the LOB table space. It does not access the base table

space or the auxiliary index.

CHECK LOB can be run in two modes:

򐂰 SHRLEVEL REFERENCE: Applications can read but cannot write.

򐂰 SHRLEVEL CHANGE: Applications can read and write (new with DB2 9).

If you plan to run CHECK DATA on a base table space containing at least one LOB column,

you might consider the following steps prior to running CHECK DATA to ensure the validity of

the LOB table spaces and auxiliary indexes. CHECK DATA relies on information in the LOB

table space and the auxiliary indexes being correct. The steps are:

1. Run CHECK LOB on the LOB table space.

2. Run CHECK INDEX on the auxiliary index.

3. Run CHECK INDEX on the base table space indexes.

If the LOB table space is in either the check pending (CHKP) status or recover pending

(RECP) status, or if the index on the auxiliary table is in rebuild pending (RBPD) status,

CHECK DATA issues an error message and fails.

CHECK LOB reports the following errors:

򐂰 Invalid LOBs

An invalid LOB is the status of a LOB as set by RECOVER when an uncorrected LOB

column error is found. CHECK LOB examines the invalid flag in the LOB table space, but it

never sets it.

򐂰 Defective LOBs

A defective LOB is a logically inconsistent LOB with a structural defect (most probably as

the result of an operational problem that left the LOB table space in an inconsistent state

or as the result of a software defect).

When the LOB table space is in CHKP status or AUXW status, and no errors are found

anymore, CHECK LOB SHRLEVEL REFERENCE resets the check pending and auxiliary

warning states. CHECK LOB SHRLEVEL CHANGE does NOT reset these pending states.

Important: If you want to run CHECK DATA when you suspect LOB errors, and you do not

want your base table space to become unavailable for applications when errors are found,

run CHECK DATA with SHRLEVEL CHANGE.

Important: CHECK LOB does not access the base table space. So, missing LOBs are not

detected during CHECK LOB.