Latest versionsfixlist FixList FixList FixList FixList FixList FixList FixList
Have problems? - contact us.
Register for free anmeldung-x26
Contact form kontakt-x26
Question in the chat LiveZilla Live Help

DB2 - Problem description

Problem IC76684 Status: Closed


Problem description:
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
Problem Summary:
* USERS AFFECTED:                                              * 
* All systems                                                  * 
* PROBLEM DESCRIPTION:                                         * 
* See Error Description                                        * 
* RECOMMENDATION:                                              * 
* This problem is a secondary symptom of crash recovery, not   * 
* typically severe, and temporary (memory is released when the * 
* first connection terminates).  In extreme cases an upgrade   * 
* may be necessary to the level containing the fix, or         * 
* alternatively the workaround may be employed.                * 
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.
available fix packs:
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 first fixed in DB2 Version 9.5 Fix Pack 9
See Local Fix
Date  - problem reported    :
Date  - problem closed      :
Date  - last modified       :
Problem solved at the following versions (IBM BugInfos)
Problem solved according to the fixlist(s) of the following version(s) FixList
This site uses cookies to make it easier for us to provide you with our services. By using our site you agree to the use of cookies.