DB2 FOR LUW / DB2FORLUW / 970 - DB2

STMM doesn't account for memory that may be committed but not 
referenced (not backed by RAM).  This memory counts towards the 
commit charge, which is backed by RAM and the paging file. 
Since STMM doesn't track whether the commit charge is getting 
close to the commit limit, it is even possible to end up 
exhausting the paging file when there is ample available system 
memory.  STMM should protect against this.  In addition, DB2's 
memory allocations may contribute to this scenario, since by 
design (for better performance), DB2 doesn't reference up front 
all memory it commits 
 
The best way to identify this scenario is from the Task Manager, 
where the Commit Charge exceeds RAM in an environment controlled 
by STMM.  "Controlled by STMM" means that self-tuning of 
database memory is enabled (SELF_TUNING_MEM = ON AND 
DATABASE_MEMORY = AUTOMATIC) and INSTANCE_MEMORY is AUTOMATIC. 
In this case we expect STMM to keep overall system memory usage 
at a level where RAM is not over-committed.

**************************************************************** 
* USERS AFFECTED:                                              * 
* systems using STMM to tune database_memory on the Windows    * 
* platform                                                     * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* See Error Description                                        * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* Upgrade to DB2 Version 9.7 Fix pack 8                        * 
****************************************************************

Set INSTANCE_MEMORY to a conservative fixed value, such as 75% 
or 50% of RAM

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 8

see local fix

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

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

01.08.2012
10.07.2013
10.07.2013

9.7.FP8