DB2 FOR LUW / DB2FORLUW / A10 - DB2

SQL1034C may occur when doing extent reclaim on index object and 
dropping all indexes within it, such as: 
 
REORG INDEXES ALL FOR TABLE T1 CLEANUP RECLAIM EXTENTS 
DROP INDEX INDX1 
... 
DROP INDEX INDXN 
 
This may result in: 
 
SQL1034C  The database is damaged.  All applications processing 
the database 
have been stopped.  SQLSTATE=58031 
 
The database then must undergo crash recovery. 
 
The following conditions must be met for the problem to occur: 
 
1) Extent reclaim of an index object. 
2) The index must be located in an old-type DMS tablespace, i.e. 
a DMS table space created before 9.7 and migrated to the current 
release. 
 
From db2diag.log, the error starts like this: 
 
2013-08-15-14.57.27.937959-240 I167322E4722          LEVEL: 
Severe 
PID     : 16643                TID : 46913369925952  KTID : 
16664 
PROC    : db2sysc 
INSTANCE: db2inst1             NODE : 000            DB   : 
SAMPLE 
APPHDL  : 0-44                 APPID: 
*LOCAL.db2inst1.130815185723 
AUTHID  : DB2INST1             HOSTNAME: myhostname 
EDUID   : 18                   EDUNAME: db2agent (SAMPLE) 
FUNCTION: DB2 UDB, buffer pool services, 
sqlbPurgeOrFlushAllPagesInSmallRange, probe:8555 
MESSAGE : ZRC=0x8402001A=-2080243686=SQLB_EMP_MAP_INFO_END "EMP 
MAP INFO END" 
DATA #1 : String, 38 bytes 
Error mapping object page to pool page 
 
The top stack trace: 
 
sqlbPurgeOrFlushAllPagesInSmallRange 
sqlbPurgeObjectLocal 
sqlbPurgeObject 
sqldmpnd 
sqlptppl 
sqlpxcm1 
sqlrrcom_dps 
sqlrrcom 
sqlrr_commit

**************************************************************** 
* USERS AFFECTED:                                              * 
* See Error Description                                        * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* See Error Description                                        * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* Upgrade to DB2 10.1 for Linux, UNIX, and Windows Fix Pack 4  * 
****************************************************************

1. Avoid extent reclaim, OR 
2. db2set DB2_HASH_PURGE_THRESH=0. A side effect is a 
potentially slower performance when dropping small objects, 
accompanied with a possible latch contention. However, if small 
objects are not being dropped frequently, this workaround will 
be acceptable. Setting DB2_HASH_PURGE_THRESH=0 reverts the 
performance of dropping small objects to the same level as 
pre-9.7 releases.

DB2 Version 10.1 Fix Pack 4 for Linux, UNIX, and Windows
 DB2 Version 10.1 Fix Pack 6 for Linux, UNIX, and Windows
 

Problem first fixed in DB2 10.1 for Linux, UNIX, and Windows Fix 
Pack 4

not known / see Local fix

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

27.11.2013
02.06.2014
02.06.2014