DB2 FOR LUW / DB2FORLUW / 970 - DB2

When performing a classic table reorganization, it is possible 
for the new reorged version of the table to take up more space 
than the original version of the table. For example, this could 
happen when setting a value for the table's PCTFREE . When a 
classic table reorg is performed using a temporary table space 
(i.e. 'USE <tempspace>' is specified on the CLP command) and the 
table grows in size,  DB2 will need to ensure that enough space 
exists for the new version of the table in the permanent table 
space where the original version of the table resides. If the 
new table is too large to fit in the existing permanent table 
space, DB2 will fail the table reorg with an SQL0289N and roll 
back. After roll back, the table remains fully accessible. Note, 
it could be that additional empty space was allocated by DB2 to 
the original version of the table in this instance. 
 
In this scenario when the classic table reorg is rolled back, 
the REORG_STATUS monitor output reports the table reorg to have 
been rolled back within the BUILD phase if there is no index on 
the table or within the REPLACE phase if an index exists on the 
table. The reporting of roll back in the REPLACE phase is 
erroneous. Once the REPLACE phase is encountered, table reorg is 
not rolled back, it is guaranteed to succeed. 
The reorg status phase will be corrected to report that a 
Classic Table Reorg has failed as part of the BUILD phase when 
reorg is unable to allocate new  pages within the table space 
for this new version of the table which is increasing in size.

**************************************************************** 
* USERS AFFECTED:                                              * 
* All                                                          * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* In certain error scenarios, reorg can fail and indicate that * 
* it failed in REPLACE phase. DB2 documentation states that a  * 
* failure in REPLACE phase cannot be rolled back. However, in  * 
* such scenarios, reorg actually failed in BUILD phase and is  * 
* erroneously reporting that it failed in REPLACE phase. Thus  * 
* a rollback is indeed possible.                               * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* Upgrade to DB2 V9.7 Fix Pack 4.                              * 
****************************************************************

DB2 Version 9.7 Fix Pack 4 for Linux, UNIX, and Windows
 DB2 Version 9.7 Fix Pack 5 for Linux, UNIX, and Windows
 DB2 Version 9.7 Fix Pack 6 for Linux, UNIX, and Windows
 DB2 Version 9.7 Fix Pack 7 for Linux, UNIX, and Windows
 DB2 Version 9.7 Fix Pack 8 for Linux, UNIX, and Windows
 DB2 Version 9.7 Fix Pack 9 for Linux, UNIX, and Windows
 DB2 Version 9.7 Fix Pack 9a for Linux, UNIX, and Windows
 DB2 Version 9.7 Fix Pack 10 for Linux, UNIX, and Windows
 

This problem was first fixed in DB2 V9.7 Fix Pack 4.

not known / see Local fix

forerunner  : APAR is sysrouted TO one or more of the following: IC72706 
follow-up : 

Date  - problem reported    :
Date  - problem closed      :
Date  - last modified       :

19.10.2010
29.04.2011
29.04.2011

9.7.FP4