After running REORG TABLESPACE

After a reorganization is complete, perform the following actions:

• If you have used LOG YES, consider taking an image copy of the reorganized table space or partition to:
  • Provide a full image copy for recovery. This action prevents the need to process the log records that are written during reorganization.
  • Permit making incremental image copies later.

  You might not need to take an image copy of a table space for which all the following statements are true:

  • The table space is relatively small.
  • The table space is used only in read-only applications.
  • The table space can be easily loaded again in the event of failure.

  In addition, you do not need to take an image copy if you used COPYDDN or FCCOPYDDN to take an inline image copy when you ran REORG.

• Use the RUNSTATS utility on the table space and its indexes if inline statistics were not collected, so that the DB2® catalog statistics take into account the newly reorganized data, and SQL paths can be selected with accurate information. You need to run RUNSTATS on nonpartitioning indexes only if you reorganized a subset of the partitions.
• If you use REORG TABLESPACE SHRLEVEL CHANGE with a mapping table, you can drop the mapping table and its index.
• If you use SHRLEVEL REFERENCE or CHANGE, and a table space, partition, or index resides in user-managed data sets, you can delete the user-managed shadow data sets.
• If you specify DISCARD on a REORG of a table that is involved in a referential integrity set, you need to run CHECK DATA for any affected referentially related objects that were placed in CHECK-pending status.