DB2 FOR LUW / DB2FORLUW / 970 - DB2

This memory leak only occurs with specific memory allocations 
made by automatic statistics collection (which is enabled via 
AUTO_RUNSTATS db cfg parameter). 
 
To detect this memory leak, check for a steady catcache growth 
from "db2pd -d <db> -memblocks sort 8" data from allocations by 
file 1191117521 from line# 320-323. For example, 
 
All memory consumers in Database memory set: 
PoolID     PoolName   TotalSize(Bytes)     %Bytes TotalCount 
%Count LOC   File 
8          catcacheh  689981592            84.94  58066 5.58 
320   1191117521 
 
Several days later, it grows up: 
PoolID     PoolName   TotalSize(Bytes)     %Bytes TotalCount 
%Count LOC   File 
8          catcacheh  759833640            91.59  63980 7.50 
320   1191117521 
 
This problem was first introduced in DB2 Version 9.7 Fixpack 1.

**************************************************************** 
* USERS AFFECTED:                                              * 
* All                                                          * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* MEMORY LEAK IN CATALOG CACHE WHEN AUTOMATIC STATISTICS IS    * 
* ENABLED.                                                     * 
*                                                              * 
* This memory leak only occurs with specific memory            * 
* allocations made by automatic statistics collection (which   * 
* is enabled via AUTO_RUNSTATS db cfg parameter).              * 
*                                                              * 
* To detect this memory leak, check for a steady catcache      * 
* growth from "db2pd -d <db> -memblocks sort 8" data from      * 
* allocations by file 1191117521 from line# 320-323. For       * 
* example,                                                     * 
*                                                              * 
* All memory consumers in Database memory set:                 * 
* PoolID  PoolName  TotalSize(Bytes)    %Bytes TotalCount      * 
* %Count LOC  File                                             * 
* 8      catcacheh         689981592     84.94      58066      * 
* 5.58 320  1191117521                                         * 
*                                                              * 
* Several days later, it grows up:                             * 
* PoolID  PoolName  TotalSize(Bytes) %Bytes TotalCount %Count  * 
* LOC  File                                                    * 
* 8      catcacheh  759833640         91.59      63980   7.50  * 
* 320  1191117521                                              * 
*                                                              * 
* This problem was first introduced in DB2 Version 9.7 Fixpack * 
* 1.                                                           * 
*                                                              * 
* The catalog cache leak might lead to evictions of catalog    * 
* cache entries when the leak grows beyond the configured      * 
* CATALOGCACHE_SZ value.  This can then lead to performance    * 
* degradations as catalog information might need to be read    * 
* again from disk to memory for various database operations    * 
* such as query compilation.                                   * 
*                                                              * 
* Because the statistics cache resides in the catalog cache,   * 
* the leak might also lead to evictions of statistics cache    * 
* entries.  This can affect the operation of RTS (real-time    * 
* statistics, enabled via AUTO_STMT_STATS database             * 
* configuration parameter).  For example, you might observe    * 
* repeated and/or multiple concurrent synchronous statistics   * 
* collections on the same table, instead of one synchronous    * 
* collection whose results stay resident in the statistics     * 
* cache where it is available for use by other agents          * 
* performing query compilations.  If you observe significant   * 
* synchronous activity in the statistics logs and if db2pd     * 
* -statisticscache data consistently shows few or no           * 
* statistics entries, the memory leak problem might be         * 
* significantly affecting RTS operations.                      * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* Update to DB2 version 9.7 fixpack 6 or newer fixpacks.       * 
****************************************************************

Disable AUTO_RUNSTATS, which is an online configurable db cfg 
parameter.  When disabled, you need to consider performing 
statistics collection manually as needed, until automatic 
statistics collection can be re-enabled.

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 is first fixed in version 9.7 fixpack 6.

Until the APAR fix can be applied, re-activate the database to 
reclaim the leaked memory and configure CATALOGCACHE_SZ 
sufficiently.  Re-activation might need to be repeated if the 
leak grows close to or beyond CATALOGCACHE_SZ. 
 
As a last resort, disable AUTO_RUNSTATS, which is an online 
configurable db cfg parameter.  When disabled, you need to 
consider performing statistics collection manually as needed, 
until automatic statistics collection can be re-enabled.

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

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

15.02.2012
11.06.2012
18.09.2012

9.7.FP6