A REORG ... DATA-AVAILABLE HIGH EXTENDED-TSREORG YES execution encounters message PRR0914E - Index ... Checksum Error within Rapid Reorg

Products

• Rapid Reorg for DB2 for z/OS

Issue/Introduction

During a Rapid Reorg for Db2 for z/OS (PRR) job an inconsistency was found between the table space and secondary indexes.
For an unknown reason there was a row in the table without an entry in the secondary indexes,
so REORG ... DATA-AVAILABLE HIGH EXTENDED-TSREORG YES statement returns error messages.

PRR0914E - Index ... Checksum Error         
           The number of reloaded keys did not match the
           number of reloaded keys for other NPIs       
           Number of keys expected: ............1,000   
           Internal Reason Code:    IB03                
PRR0186E - Index ... Failed REBUILD    

Working with REORG ... DATA-AVAILABLE CRITICAL EXTENDED-TSREORG NO and REORG ... DATA-AVAILABLE HIGH EXTENDED-TSREORG NO statements
 do not return these error messages. 

Resolution

EXTENDED-TSREORG YES although with REBUILD-INDEX YES will strip keys from the existing index, update the RIDs from the reorg, and REBUILD the index.
This is a faster methodology but assumes the table space data and indexes are consistent at the start of the reorg. It does not build a key from the tablespace data.
It uses the existing key. CHECKSUM logic is used to check the count of rows to keys and keys to keys for all NPI's to ensure this is true.
If CHECKSUM detects a problem or inconsistency the index will be rebuilt via AUTO-RECOVER, the index is then built from the table space data.

DATA-AVAILABLE CRITICAL EXTENDED-TSREORG NO and DATA-AVAILABLE HIGH EXTENDED-TSREORG NO will always build all indexes from the
table space data so there is never an issue with CHECKSUM logic. Using DATA-AVAILABLE HIGH EXTENDED-TSREORG NO is a quick way of recovering indexes.