|
Problem IC64487
|
Status: Closed |
SQL0973 MEMORY ALLOCATION FAILURE FROM LOAD UTILITY |
| product: |
DB2 FOR LUW / DB2FORLUW / 970 - 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 Utiltiy Heap setting AND running LOAD *
* utility, especially concurrent/frequent LOADs *
****************************************************************
* PROBLEM DESCRIPTION: *
* See Error Description *
****************************************************************
* RECOMMENDATION: *
* Update DB_MEM_THRESH = 100 *
**************************************************************** |
| 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.7 Fix Pack 3 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 3a for Linux, UNIX, and Windows
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 Version 9.7 Fix Pack 3 build s101006 |
| Workaround |
not known / see Local fix |
| Timestamps |
Date - problem reported :
Date - problem closed :
Date - last modified :
| 11.11.2009
02.11.2010
02.11.2010 |
| Problem solved at the following versions (IBM BugInfos) |
9.7.FP3
|
| Problem solved according to the fixlist(s) of the following version(s) |
| 9.7.0.3
|
 |
| 9.7.0.3
|
|
