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 IC73734 Status: Closed

DB2SYSCS.EXE PROCESS VIRTUAL MEMORY EXHAUSTION ON 32-BIT WINDOWS DUE TO
FRAGMENTATION

product:
DB2 FOR LUW / DB2FORLUW / 970 - DB2
Problem description:
The DB2 server process, db2syscs.exe, on 32-bit Windows may 
experience memory exhaustion due to excessive fragmentation in 
DB2's private memory areas.  The problem is caused by releasing 
portions of virtual allocations to reduce real memory 
consumption, this causes fragmentation between "free" managed 
areas and "commited" managed areas. 
 
Symptoms include: 
- Windows memory analysis tools (such as vadump) reports growing 
or large reserved memory areas. 
- DB2's STMM (Self-Tuning Memory Manager) may gradually tune 
down Database Memory as it is sensitive to available virtual 
process memory space. 
- db2diag.log may report virtual memory exhaustion.  For 
example: 
 
FUNCTION: DB2 UDB, SQO Memory Management, 
sqloLogMemoryCondition, probe:100 
CALLED  : OS, -, VirtualAlloc 
OSERR   : 8 "Not enough storage is available to process this 
command." 
MESSAGE : Private memory and/or virtual address space exhausted
Problem Summary:
**************************************************************** 
* USERS AFFECTED:                                              * 
* Systems running 32-bit Windows                               * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* See Error Description                                        * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* Upgrade to DB2 9.7 Fix Pack 4.  db2set DB2MEMDISCLAIM=NO can * 
* be used as a temporary workaround.                           * 
****************************************************************
Local Fix:
A workaround is: 
  db2set DB2MEMDISCLAIM=NO 
recycle the instance (db2stop, db2start) 
This returns the behaviour to versions previous to 9.5.  Memory 
will be released only by freeing complete virtual allocations.
available fix packs:
DB2 Version 9.7 Fix Pack 4 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 5 for Linux, UNIX, and Windows
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

Solution
Problem first fixed in DB2 9.7 Fix Pack 4
Workaround
see Recommendation
Timestamps
Date  - problem reported    :
Date  - problem closed      :
Date  - last modified       :
07.01.2011
29.04.2011
29.04.2011
Problem solved at the following versions (IBM BugInfos)
9.7.FP4
Problem solved according to the fixlist(s) of the following version(s)
9.7.0.4 FixList