DB2 FOR LUW / DB2FORLUW / A10 - 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:                                              * 
* DB2 Server on Windows platform                               * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* See Error Description                                        * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* Upgrade to DB2 Version 10.1 Fix Pack 2                       * 
****************************************************************

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

First fixed in DB2 Version 10.1 Fix Pack 2

See Local Fix

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

03.08.2012
17.12.2012
17.12.2012