Restarting REORG PLUS
For a SHRLEVEL CHANGE (single- or two-phase) reorganization, you cannot restart any time before the beginning of the UTILTERM phase, unless you are restarting after ANALYZE PAUSE. Until UTILTERM begins, all user updates are made to the original data sets, which the reorganization has not yet changed. The data sets are exactly as they were before you ran the reorganization. After UTILTERM begins, restart works the same as it does for any other type of reorganization. For more information about restarting a SHRLEVEL CHANGE reorganization, see Restart-considerations-for-a-SHRLEVEL-CHANGE-reorganization.
For all other types of reorganizations, with exceptions described in the following sections, you can restart REORG PLUS from a failure during any phase as long as the SYSRECnn and SYSUT1nn data sets are present and are defined as cataloged data sets. Dynamically allocated SYSRECnn, SYSUT1nn, and copy data sets are automatically reallocated by REORG PLUS on restart.
You cannot make structural changes to objects, including creating a pending definition change, before restarting a failed reorganization. REORG PLUS relies on the object structure to remain unchanged between restart and the original run. If you change the structure between runs, REORG PLUS might issue a user abend 3200 with reason code 5 or produce unpredictable results.
Specifying the RESTART and RESTART(PHASE) options
If a reorganization fails, correct the problem and restart the reorganization either with RESTART or RESTART(PHASE). REORG PLUS issues messages as it unloads, reloads, or rebuilds each Db2 object. The BMCSYNC table contains an entry for each Db2 object involved in the reorganization and its current status.
Specify RESTART without (PHASE) to restart REORG PLUS from the last restart sync point. REORG PLUS takes restart sync points as each phase completes and as the processing of each Db2 object completes. The utility ID must exist in the BMCUTIL table.
Specify RESTART(PHASE) to restart REORG PLUS at the beginning of the last incomplete phase. The utility ID must exist in the BMCUTIL table.
Additional restart considerations and restrictions
This section describes additional considerations and restrictions that you should be familiar with before you restart a REORG PLUS job. For detailed instructions about dealing with a failure during the reorganization, see Recovering-from-a-failure.
LOB table spaces
If a failure occurs during the index rebuilding process of a LOB table space reorganization, restarting the job causes REORG PLUS to reorganize the LOB table space again.
XML table spaces
The following considerations apply when the table space contains a document ID index for which REORG PLUS has generated document ID values. REORG PLUS might generate document ID values if the original job is the first reorganization after adding the first XML column to the table.
- When both of the following conditions exist, you can restart the reorganization, but the index will be left in PSRBD status after the restarted job completes:
- SHRLEVEL NONE is in effect for a partial table space reorganization.
- The failure occurs after REORG PLUS has started updating the index.
- When all of the following conditions exist, REORG PLUS changes RESTART(PHASE) to RESTART and the table space is not reloaded again in the restarted job:
- You specify RESTART(PHASE) to restart a partial table space reorganization for which the following options were in effect:
- SHRLEVEL NONE
- UNLOAD RELOAD
- During the original job or an earlier job, the document ID index was successfully updated.
- The original job failed after the table space was reloaded.
- You specify RESTART(PHASE) to restart a partial table space reorganization for which the following options were in effect:
Partition-by-growth table spaces
The following restrictions and considerations apply when you restart a reorganization of a partition-by-growth table space:
- If MAXPARTITIONS is altered before you restart a job, REORG PLUS does not honor increases (ALTERs) to MAXPARTITIONS before a restarted job. If REORG PLUS detects such an ALTER, it issues message BMC50177I and continues with the reorganization as though the original MAXPARTITIONS value were in effect.
- You cannot change the value of the MAXNEWPARTS option; doing so causes the REORG PLUS job to fail.
- If a SHRLEVEL NONE reorganization fails during reload processing in a single-phase reorganization or unload processing in a two-phase reorganization because insufficient space is available, (indicated by message BMC50174E or message BMC51287E), we recommend that you perform an ALTER TABLESPACE to either decrease PCTFREE or FREEPAGE or increase MAXROWS, and then restart the job.
Compressed indexes
The following considerations apply when a compressed, non-unique, nonpartitioned index is participating in the reorganization:
- When both of the following conditions exist, you can restart the reorganization, but the index will be left in PSRBD status after the restarted job completes:
- SHRLEVEL NONE is in effect for a partial table space reorganization.
- The failure occurs after REORG PLUS has started updating the index.
- When all of the following conditions exist, REORG PLUS changes RESTART(PHASE) to RESTART and the table space is not reloaded again in the restarted job:
- You specify RESTART(PHASE) to restart a partial table space reorganization for which the following options were in effect:
- SHRLEVEL NONE
- UNLOAD RELOAD
- During the original job or an earlier job, the index was successfully updated.
- The original job failed after the table space was reloaded.
- You specify RESTART(PHASE) to restart a partial table space reorganization for which the following options were in effect:
Non-data-sorting indexes
When restarting a failed SHRLEVEL REFERENCE partial reorganization with non-data-sorting indexes, refer to the following table to determine whether non-data-sorting indexes that were copied before the failure are recopied during restart processing. If all data sets of a multi-data-set index are not copied before the restart, the entire multi-data-set index is recopied.
Recopying of data sets for restart processing
Type of reorganization | Phase for restart | Data sets recopied when RESTART | Data sets recopied when RESTART(PHASE) |
---|---|---|---|
Single-phase | REORG phase | No | Yes |
Two-phase | UNLOAD phase | No | Yes |
RELOAD phase | No | No |
Objects with pending definition changes
The following considerations apply when restarting a reorganization on an object with pending definition changes:
You can restart the reorganization only if the FASTSWITCH or rename process is completed.
For more information, see Managing-a-reorganization-that-does-not-complete-in-the-UTILTERM-phase.
- REORG PLUS ignores any pending definition changes that occurred before you restarted the reorganization.
Data sharing environment
On the restart in a data sharing environment, REORG PLUS can use either the same member chosen in the original reorganization or any other member in the specified group.
SELECT and DELETE processing
You cannot restart a job that fails in the REORG phase when all of the following conditions exist:
- You are performing a SHRLEVEL NONE single-phase reorganization.
- You allocated an SYSARC data set.
- You are performing SELECT or DELETE processing.
Statistics
The following considerations apply to restarted jobs when you specify BMCSTATS YES or UPDATEDB2STATS YES:
- On the restart, REORG PLUS does not update statistics if, in the original job, any participating table space partitions were completely loaded or any participating index partitions were completely built.
- You can change the TSSAMPLEPCT option when restarting a reorganization.
Failure due to inadequate space
Failure during the RELOAD or REORG phase can result in an unusable table space (not applicable for SHRLEVEL REFERENCE or SHRLEVEL CHANGE). The most likely cause of this failure is inadequate space in the Db2 data set. If the space is inadequate, either specify REDEFINE NO (command or installation option) and allocate new data sets for those that caused the failure or increase the primary or secondary space values. Then restart the reorganization with the RESTART option. If you decide to reallocate any data sets that were successfully reloaded or rebuilt, however, you must restart the reorganization with RESTART(PHASE).
On any restart after UTILINIT, REORG PLUS does not use any changes to FREEPAGE, PCTFREE, MAXROWS, or PIECESIZE values. If REORG PLUS terminates with message BMC51287E, you must resubmit the job with an execution parameter of NEW.
CLONE option
You cannot add or remove the CLONE option when restarting a reorganization.
DELETEFILES
To restart your job during DELETEFILES processing, specify RESTART without (PHASE).
DSNUTILB reorganization
When restarting a DSNUTILB reorganization job, REORG PLUS passes the RESTART or RESTART(PHASE) parameter that you specified to DSNUTILB for processing.
Dynamic allocation
On the restart, REORG PLUS automatically reallocates dynamically allocated data sets.
If you change any dynamic data set allocation option on a restart and the change results in different ddnames or a different number of DDs than the original option had, you can receive an error. If you need to change the number of SYSREC or SYSUT1 data sets, you must resubmit the job with a parameter of NEW.
You cannot change the value for the ACTIVE option on any restart. To change the value of other dynamic data set allocation options, specify RESTART(PHASE).
Inline image copies
If you restart a SHRLEVEL NONE or SHRLEVEL REFERENCE table space reorganization job, REORG PLUS changes the value of the INLINE command to NO if all of the following statements are true:
- The table space is partitioned.
- You have a single image copy data set.
- At least one (but not all) of the partitions was reloaded before the failure.
This change occurs regardless of the value you specified for the INLINE command or the INLINECP installation option.
TERM and FORCEID
You can specify TERM as the restart parameter in a classic utility EXEC statement. If the Overview-of-SmartSwitch-feature "switches" a REORG PLUS job to the BMC AMI Reorg for Db2 (BMC AMI Reorg) product, SmartSwitch translates TERM to QUICKEXIT. For information about QUICKEXIT in BMC AMI Reorg, seeQUICKEXIT.
In some cases, after a job has switched to BMC AMI Reorg, you might prefer to use FORCEID instead of QUICKEXIT to clean up an abended job (for example, if the job is in must complete status). Unlike QUICKEXIT, FORCEID quickly cleans the UTILID from both the BMCUTIL table and the BMC AMI Utilities checkpoint without the need to submit a separate job. For more information about FORCEID, seeFORCEID.
You can specify FORCEID as the restart parameter in REORG PLUS EXEC statements. In REORG PLUS, FORCEID operates as if you had specified TERM. If the SmartSwitch feature switches the job to BMC AMI Reorg, the job runs as if you had specified FORCEID in the BMC AMI Reorg JCL.