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.

Get LOBs with DB2 for z/OS: Stronger and Faster now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.