This topic describes the following NGT Reorg features.
NGT Reorg can optionally update the DB2 catalog with the RUNSTATS values calculated at the end of a reorganization.
If you reorganize only a subset of partitions, NGT Reorg updates statistics for those partitions and recomputes the composite statistics.
Concurrent copy support
Concurrent copies are made at the same time as a load or reorganization.
NGT Reorg will create concurrent DB2 image copies during a reorganization on any table space. A separate run is not required.
Concurrent copy support uses DASD, tape, or VTS. These copies are compatible with DSN1COPY. The following considerations apply for cartridge tapes needed for offsite storage:
- The recovery site copy should go to DASD that is immediately HSM-migrated to tape. This makes efficient use of tape and shortens recovery time by allowing for recall prior to starting the recovery.
- Use a virtual tape system that has external tapes that can be taken offsite and brought back. This makes efficient use of tapes and buffers them to DASD for faster recovery times.
NGT Reorg posts reorganizations and all concurrent copies in the DB2 SYSIBM.SYSCOPY catalog table. The reorganization is posted as LOG(NO).
NGT Reorg deletes rows from the table during a reorganization when either of the following conditions exists:
- You specify DISCARD on the REORG command.
- The reorganization materializes pending limit key changes, and rows exist after the new last limit key.
|Discards due to a DISCARD specification|
The DISCARD option uses a WHERE clause that specifies which rows to delete during the REORG.
The WHERE clause supports the following functions:
For more information about the DISCARD option, including restrictions, see DISCARD. For more information about the WHERE clause, including syntax and restrictions, see .
|Discards due to altered limit keys|
After materializing pending limit key changes, NGT Reorg deletes any rows found after the new last limit key. For more information, see Pending limit key changes.