DB2 FOR LUW / DB2FORLUW / 950 - DB2

Generally, a firstly connecting agent (in this case it is STMM, 
db2stmm) reads SYSIBM.SYSVERSIONS and it may read an index of 
SYSIBM.SYSVERSIONS.  At that timing, if the index is marked as 
needed to be rebuilt, will do so and writes logical log records. 
 But DB2 does not make a "commit" at the end so it may cause 
SQL0964 Logfull. 
 
Here is an example problem reproducible scenario: 
================================================= 
mkdir /backup 
mkdir /logs 
mkdir /DB 
 
db2start 
db2 drop db sample 
db2sampl 
db2 connect to sample 
db2 update db cfg for sample using LOGARCHMETH1 disk:/logs 
db2 terminate 
db2 backup database sample to /dev/null 
 
### test 
 
db2 deactivate db sample 
db2 backup db sample to /backup compress 
db2 activate db sample 
db2 connect to sample 
db2 reorg table sysibm.sysversions use tempspace1 
db2 terminate 
db2 deactivate db sample 
db2 restore db sample from /backup to /DB without prompting 
db2 "rollforward db sample to end of logs and stop" 
db2 activate db sample 
 
### now look at the db by follows 
 
db2 list applications show detail 
db2 get snapshot for all databases global 
 
### Appl id holding the oldest transaction = stmm 
================================================= 
 
In the above scenario, "reorg table sysibm.sysversions" may need 
to rebuild an index.  If you restore the database with a backup 
image which is taken before the "reorg table" and rollforward to 
end of logs, DB2 should rebuild the index.  There are two ways 
to rebuilt it, 1) write a rebuild index required logcal log, set 
the index as invalid state at rollforwad and then rebuld it when 
an agent finds the index is needed to rebuild. 
2) write all index rebuld logical logs then apply and reply all 
those logs to rebuld the index.  Default db cfg LOGINDEXBUILD 
OFF setting works as 1).  Based on these, users may work around 
by setting LOGINDEXBUILD ON. 
 
Potentially below agents may cause this problem as same as STMM: 
ABP task daemon, WLM stats collector daemon, event monitors, 
online reorg, redistribute, HADR. 
We will fix as well.

**************************************************************** 
* USERS AFFECTED:                                              * 
* DB2 UDB Version 9.5                                          * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* See Error description field for more information.            * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* Upgrade to Version 9.5 FixPack 7.                            * 
****************************************************************

Users may work around by: 
db2 update db cfg for DBNAME using LOGINDEXBUILD ON 
 
and 
 
( 
  db2 update db cfg for DBNAME using INDEXREC RESTART 
or 
 (db2 update db cfg for DBNAME using INDEXREC SYSTEM 
 
  and 
 
  db2 update dbm cfg using INDEXREC RESTART ) 
)

DB2 Version 9.5 Fix Pack 7 for Linux, UNIX, and Windows
 DB2 Version 9.5 Fix Pack 8 for Linux, UNIX, and Windows
 DB2 Version 9.5 Fix Pack 9 for Linux, UNIX, and Windows
 DB2 Version 9.5 Fix Pack 10 for Linux, UNIX, and Windows
 

Problem was first fixed in DB2 UDB Version 9.5 FixPack 7.

keiner bekannt / siehe Local-Fix

Vorgänger  : APAR is sysrouted TO one or more of the following: IC69295 IC69296 
Nachfolger : 

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

16.06.2010
11.01.2011
11.01.2011

9.5.FP7