Saturday, December 25, 2010

Termination of REORG TABLESPACE

Hello my blog readers...

It is truely a concern when the REORG of the table terminated. Here is one of the most important facts regarding Reorg failure and termination which I have collected from IBM manual and shared with you for your benefit.



You can terminate the REORG TABLESPACE utility.

If you terminate REORG TABLESPACE with the TERM UTILITY command during the UNLOAD phase, objects have not yet been changed, and you can rerun the job.

If you terminate REORG TABLESPACE with the TERM UTILITY command during the RELOAD phase, the behavior depends on the SHRLEVEL option:

•For SHRLEVEL NONE, the data records are not erased. The table space and indexes remain in RECOVER-pending status. After you recover the table space, rerun the REORG job.

•For SHRLEVEL REFERENCE or CHANGE, the data records are reloaded into shadow objects, so the original objects have not been affected by REORG. You can rerun the job.

If you terminate REORG with the TERM UTILITY command during the SORT, BUILD, or LOG phases, the behavior depends on the SHRLEVEL option:

•For SHRLEVEL NONE, the indexes that are not yet built remain in RECOVER-pending status. You can run REORG with the SORTDATA option, or you can run REBUILD INDEX to rebuild those indexes.

•For SHRLEVEL REFERENCE or CHANGE, the records are reloaded into shadow objects, so the original objects have not been affected by REORG. You can rerun the job.

If you terminate a stopped REORG utility with the TERM UTILITY command during the SWITCH phase, the following conditions apply:

•All data sets that were renamed to their shadow counterparts are renamed to their original names, so that the objects remain in their original state, and you can rerun the job.

•If a problem occurs in renaming the data sets to the original names, the objects remain in RECOVER-pending status, and you cannot rerun the job.

If the SWITCH phase does not complete, the image copy that REORG created is not available for use by the RECOVER utility. If you terminate an active REORG utility during the SWITCH phase with the TERM UTILITY command, during the rename process, the renaming occurs, and the SWITCH phase completes. The image copy that REORG created is available for use by the RECOVER utility.

The REORG-pending status is not reset until the UTILTERM execution phase. If the REORG utility abnormally terminates or is terminated, the objects remain in REORG-pending status and RECOVER-pending status, depending on the phase in which the failure occurred.

The following table lists the restrictive states that REORG TABLESPACE sets according to the phase in which the utility terminated.

Table 1. Restrictive states that REORG TABLESPACE sets. Phase Effect on restrictive status

UNLOAD No effect.

RELOAD SHRLEVEL NONE:

•Places table space in RECOVER-pending status at the beginning of the phase and resets the status at the end of the phase.

•Places indexes in RECOVER-pending status.

•Places the table space in COPY-pending status. If COPYDDN is specified and SORTKEYS is ignored, the COPY-pending status is reset at the end of the phase. SORTKEYS is ignored for several catalog and directory table spaces

SHRLEVEL REFERENCE or CHANGE has no effect.

SORT No effect.

BUILD SHRLEVEL NONE resets RECOVER-pending status for indexes and, if the utility job includes both COPYDDN and SORTKEYS, resets COPY-pending status for table spaces at the end of the phase. SHRLEVEL REFERENCE or CHANGE has no effect.

SORTBLD No effect during the sort portion of the SORTBLD phase. During the build portion of the SORTBLD phase, the effect is the same as for the BUILD phase.

LOG No effect.

SWITCH No effect. Under certain conditions, if TERM UTILITY is issued, it must complete successfully; otherwise, objects might be placed in RECOVER-pending status.

Recovering a failed REORG job

If you terminate REORG SHRLEVEL NONE in the RELOAD phase, all SYSLGRNX records associated with the reorganization are deleted. Use the RECOVER TABLESPACE utility to recover to the current point in time. This action recovers the table space to its state before the failed reorganization.

Example 1: Recovering a table space. The following control statement specifies that the RECOVER utility is to recover table space DSN8D81A.DSN8S81D to the current point in time.

RECOVER TABLESPACE DSN8D81A.DSN8S81D


Cheers.. and Merry Christmas!!!


Regards,
Prakash C. Singh
IBM Certified DB2 DBA.

1 comment:

Anonymous said...

Hi, I always used DB2 REORAG SHRLEVEL(CHANGE). At my customer site, they installed a new REORG tool. We are in DB2v9 now. Last year, my customer 'accidentally' REORG a partition TS using both IBM REORG and the third party REORG tool on the same partition TS ( this will caused conflict among the 2 tools). In short, DB2 REORG Utility abended, and SYSUTILX corrupted, as we couldn't issue TERM UTIL(*) command. We recovered SYSIBM.SYSUTILX (drop, redefined). New utilities are ok, can be ran and terminated. However, the mapping table and indexes that were hanging, still registered in DB2. Now, when I want to drop and recreate the mapping table or index, DB2 returned error 'onject is used in another utility'. Dropping of mapping objects are not possible. Do you have any tips how I can clean up this ?
thanks ...I can be contacted at kimchin@gmail.com