Db2 Utilities and Data Movement
This domain covers COPY, REORG, RUNSTATS, LOAD, UNLOAD, CHECK, and the utility control statements that make them safe and efficient.
Core rules
- COPY produces full or incremental image copies. Inline copies are taken during REORG or LOAD and reduce the need for a separate COPY.
- REORG SHRLEVEL CHANGE keeps data available. It requires LOG(YES) and careful handling of mapping tables for partition-by-growth. SHRLEVEL REFERENCE allows read-only access; SHRLEVEL NONE is offline.
- LOAD REPLACE or RESUME can run with LOG(NO), which makes the table unrecoverable without a fresh copy. LOAD is generally not an online utility; use inline statistics and COPY YES where appropriate.
- RUNSTATS can run inline with REORG or LOAD; consider COLGROUP, HISTOGRAM, and sampling. CHECK DATA, CHECK INDEX, and CHECK LOB validate integrity.
- Utilities use LISTDEF and TEMPLATE for scale, and profiles to standardize options.
Worked example
A DBA runs REORG SHRLEVEL CHANGE with inline COPY and inline RUNSTATS on a large PBG table. Reasoning: SHRLEVEL CHANGE keeps the table available, the inline copy supplies a recoverable image, and inline RUNSTATS avoids a separate scan; a mapping table is needed if the table space grows during REORG.
Traps
- LOAD REPLACE LOG(NO) without an immediate COPY leaves no recovery path.
- Inline COPY and inline RUNSTATS are separate options.
- A failed REORG can leave REORG-pending; check SYSIBM.SYSUTILX and the utility ID.
- RUNSTATS sampling that is too small produces misleading cardinalities and bad access paths.