DB2 FOR LUW / DB2FORLUW / 970 - DB2

A memory leak occurs during database activation/first connect 
when crash recovery is required and INDEXREC is set to RESTART. 
This is the default setting and causes DB2 to check whether any 
indexes require rebuilding after the recovery phase is complete. 
 
The leak is temporary and will be released when the first 
connection terminates.  In DPF the leak on the catalog partition 
is magnified by the number of partitions being activated (and 
requiring crash recovery).   Note that the first connection may 
not be for the same application on all partitions - in this case 
a smaller leak may show up across a number of application heaps. 
The amount of the memory leak for a single partition is 
approximately the result of the following query: 
 
db2 "select sum(length(packed_desc)) from sysibm.systables where 
TYPE!='T' and TYPE !='H' and TYPE!='' " 
 
If system or DB2 memory usage is high after activating a 
database, consult the db2diag.log as to whether crash recovery 
occurred.  There will be a message similar to the following: 
 
FUNCTION: DB2 UDB, base sys utilities, sqledint, probe:30 
MESSAGE : Crash Recovery is needed. 
 
Also consult application and database snapshots to determine 
whether there is an application which: 
a) has high memory usage in the Application Heap 
b) has a connection timestamp matching the first connection time 
in the database snapshot 
 
"db2pd -db <database> -memb" will show a large number of memory 
blocks similar to the following: 
(Some columns have been omited) 
 
PoolID  PoolName  Size(Bytes)  File 
1          apph         3120           882766201 
1          apph         2728           882766201 
1          apph         4880           882766201

**************************************************************** 
* USERS AFFECTED:                                              * 
* All environments                                             * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* See Error Description                                        * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* Upgrade to DB2 Version 9.7 Fix Pack 5 or use workaround in   * 
* Local Fix.                                                   * 
****************************************************************

The problem can be avoided by setting the database configuration 
parameter INDEXREC to ACCESS: 
db2 update db cfg for <database> using INDEXREC ACCESS 
 
When indexes need to be rebuilt after crash recovery, the first 
application which accesses the table will force an index 
rebuild.  The impact on applications should be taken into 
account as the affected application will be stalled until index 
rebuild is complete.

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
 

Problem first fixed in DB2 Version 9.7 Fix Pack 5

See Local Fix

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

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

19.05.2011
05.06.2012
05.06.2012

9.7.FP5