home clear 64x64
en blue 200x116 de orange 200x116 info letter User
suche 36x36
Latest versionsfixlist
11.1.0.7 FixList
10.5.0.9 FixList
10.1.0.6 FixList
9.8.0.5 FixList
9.7.0.11 FixList
9.5.0.10 FixList
9.1.0.12 FixList
Have problems? - contact us.
Register for free anmeldung-x26
Contact form kontakt-x26

DB2 - Problem description

Problem IC89145 Status: Closed

STMM MAY OVERCOMMIT MEMORY ON WINDOWS SYSTEMS, RESULTING IN PAGING SPACE
EXHAUSTION

product:
DB2 FOR LUW / DB2FORLUW / A10 - DB2
Problem description:
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.
Problem Summary:
Local Fix:
Set INSTANCE_MEMORY to a conservative fixed value, such as 75% 
or 50% of RAM
Solution
Workaround
not known / see Local fix
Comment
This APAR is a duplicate of IC85729
Timestamps
Date  - problem reported    :
Date  - problem closed      :
Date  - last modified       :
17.12.2012
28.01.2013
28.01.2013
Problem solved at the following versions (IBM BugInfos)
Problem solved according to the fixlist(s) of the following version(s)