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

SQL0973 MEMORY ALLOCATION FAILURE FROM LOAD UTILITY

product:
DB2 FOR LUW / DB2FORLUW / 950 - DB2
Problem description:
Beginning with DB2 version 9.5 Fixpak 3 and Version 9.7 GA, LOAD 
memory allocation behaviour changed.  While it is more 
efficient, in some cases a combination of fragmentation and 
large allocations can result in SQL0973N - failure to allocate 
memory from the Utility Heap. 
 
The expected db2diag.log entry is : 
2009-09-22-21.52.37.592451-240 I367406661E568    LEVEL: Error 
PID : 8318         TID  : 193441294688 PROC : db2sysc 2 
INSTANCE: db2inst1        NODE : 000   DB   : SAMPLE 
APPHDL : xxxxx         APPID: xxxxx 
AUTHID : db2inst1 
EDUID : 4582         EDUNAME: db2lload 0 
FUNCTION: DB2 UDB, database utilities, DIAG_ERROR, probe:0 
DATA #1 : String, 145 bytes 
LOADID: 51624.2009-09-22-21.52.36.240048.10 (7;784) 
Failed to enable fast memblocks , -1961951227, (nil), Detected 
in file:sqlulbuf2.C, Line:1773 
 
If db2pd -db <db> -memsets can be issued after the failure, it 
may be observed that there is a sufficient amount of unused 
commited memory available in database memory : 
 
Memory Sets: 
Name      Size(Kb)  Unrsv(Kb)  Used(Kb)   HWM(Kb)   Cmt(Kb) 
Uncmt(Kb) 
SAMPLE    13851968   5897216  6837888    7721600    13562240 
70400 
 
In the above example, Commited memory is far above Used memory, 
and should be available for LOAD, which instead failed with 
SQL0973N.
Problem Summary:
**************************************************************** 
* USERS AFFECTED:                                              * 
* Systems with large Utility Heap settings running Loads       * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* See Error Description                                        * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* Upgrade or use documented workaround                         * 
****************************************************************
Local Fix:
A workaround exists.  Increasing the amount of commited memory 
that DB2 will cache will reduce fragmentation, allowing large 
allocations to succeed.  This can be accomplished by the command 
: 
" db2 update db cfg for <database> using DB_MEM_THRESH 100 " 
This is dynamic if issued while connected to the database.  Some 
increase in memory usage may be observed.
available fix packs:
DB2 Version 9.5 Fix Pack 6a for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 7 for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 8 for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 9 for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 10 for Linux, UNIX, and Windows

Solution
Problem first fixed in DB2 Version 9.5 Fix Pack 6
Workaround
not known / see Local fix
BUG-Tracking
forerunner  : APAR is sysrouted TO one or more of the following: IC64487 IC68464 
follow-up : 
Timestamps
Date  - problem reported    :
Date  - problem closed      :
Date  - last modified       :
10.11.2009
14.06.2010
16.07.2010
Problem solved at the following versions (IBM BugInfos)
9.5.FP6
Problem solved according to the fixlist(s) of the following version(s)