DB2 FOR LUW / DB2FORLUW / 970 - DB2

A DB2 instance can encounter a programming error message during 
an index update operation. 
 
Possible stack: 
 
pthread_kill 
sqloDumpEDU 
sqldDumpContext 
sqlidelk 
sqlidelk 
sqldUpdateIndexes 
sqlriupd 
 
db2diag.log: 
 
2012-06-15-11.44.37.192742-240 I41733E537  LEVEL: Severe 
PID     : 20122        TID  : 469129463012 PROC : db2sysc 
INSTANCE: dbuser1      NODE : 000          DB   : SAMPLEDB 
APPHDL  : 0-7          APPID: *LOCAL.dbuser1.120615154434 
AUTHID  : DBUSER1 
EDUID   : 16           EDUNAME: db2agent (SAMPLEDB) 
FUNCTION: DB2 UDB, index manager, sqliCleanupEmptyLeaf, 
probe:1213 
RETCODE : ZRC=0x87090054=-2029453228=SQLI_PRG_ERR "Program 
error" DIA8575C An index manager programming error occurred. 
 
2012-06-15-11.44.37.212833-240 I42271E741  LEVEL: Severe 
PID     : 20122        TID  : 469129463012 PROC : db2sysc 
INSTANCE: dbuser1      NODE : 000          DB   : SAMPLEDB 
APPHDL  : 0-7          APPID: *LOCAL.dbuser1.120615154434 
AUTHID  : DBUSER1 
EDUID   : 16           EDUNAME: db2agent (SAMPLEDB) 
FUNCTION: DB2 UDB, trace services, sqlt_logerr_string (secondary 
logging fu, probe:0 
DATA #1 : String, 173 bytes 
Running the following command before and after restart database 
may provide useful problem determination information.  Replace 
DBNAME with the real DB name if not provided. 
DATA #2 : String, 87 bytes 
db2dart SAMPLEDB /di /tsi 7 /oi 4 /ps 114  /np 1 /v y /scr n 
/rptn iTsi7oi4pg114o+0.rpt 
 
... 
 
2012-06-15-12.03.54.627008-240 E160694E966 LEVEL: Critical 
PID     : 24172        TID  : 469129463012 PROC : db2sysc 
INSTANCE: dbuser1      NODE : 000          DB   : SAMPLEDB 
APPHDL  : 0-7          APPID: *LOCAL.dbuser1.120615160352 
AUTHID  : DBUSER1 
EDUID   : 16           EDUNAME: db2agent (INDPDDB) 
FUNCTION: DB2 UDB, base sys utilities, 
sqeLocalDatabase::MarkDBBad, probe:10 
MESSAGE : ADM14001C  An unexpected and critical error has 
occurred:  "DBMarkedBad". The instance may have been shutdown as 
a result. "Automatic" FODC (First Occurrence Data Capture) has 
been invoked and diagnostic information has been recorded in 
directory 
"/home/dbuser1/sqllib/db2dump/FODC_DBMarkedBad_2012-06-15-12.03. 
54.626917_0000/". Please look in this directory for detailed 
evidence about what happened and contact IBM support if 
necessary to diagnose the problem. 
 
The database will get marked as bad, and will require Crash 
recovery.  The databsae should complete crash recovery without 
any problems, however the index object is damaged and needs to 
be recreated (see the Local Fix section). 
 
To confirm that this problem has been hit, you need to check the 
transaction logs.  Look for the "sqliCleanupEmptyLeaf, 
probe:1213" error in the db2diag.log, then search down for a 
db2dart command.  Shown above. 
 
Look for this rpt file in one of the FODC_IndexError* 
directories, open it and note the Page LSN: 
Page LSN = 0000000002B72B11 
 
Then find this LSN in the transaction logs and examine the 
transaction it is a part of.  If this APAR was hit you will see 
the following in that transaction: 
- CRINDEX_DP log record for the object reference in the db2dart 
command 
- A SQLI_LRT_MARK_INX_BAD and SQLD_LRT_CHANGELIFELSN log record 
indicating that CREATE INDEX has completed followed by 
- A GETPAGE_DP log record with the same root page that appears 
in the CRINDEX_DP log record 
- The transaction rolls back and aborts

**************************************************************** 
* USERS AFFECTED:                                              * 
* All Platforms                                                * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* a DB2 instance can encounter a programming error message     * 
* during                                                       * 
* an index update operation.                                   * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* Upgrade to DB2 V9.7 Fix Pack 5.                              * 
****************************************************************

To avoid hitting problem, the customer should COMMIT any CREATE 
INDEX statements immediately after the CREATE INDEX statement 
has completed, instead of including the CREATE INDEX as a part 
of a larger transaction. 
 
To recover from the probelm if hit, the user should recreate the 
index object by either: 
- running REORG INDEXES ALL on the table with either the ALLOW 
NO ACCESS or the ALLOW READ ACCESS option OR 
- marking the index object invalid using db2dart and rebuild it 
OR 
- dropping all indexes on the table (including ones created 
implicitly for primary keys and unique constraints) and then 
recreating them

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 5.

keiner bekannt / siehe Local-Fix

Datum - Problem gemeldet    :
Datum - Problem geschlossen :
Datum - der letzten Änderung:

27.07.2011
27.12.2011
15.06.2012

9.7.FP5