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

UNEXPECTED OOM ERRORS AFTER A LARGE DYNAMIC DATABASE CONFIGURATION
INCREASE

product:
DB2 FOR LUW / DB2FORLUW / B10 - DB2
Problem description:
After increasing the configured database memory size, the DB2
memory manager may not always allocate the underlying OS memory
permitted as part of the increase, resulting in intermittent out
of memory errors.

When dynamically increasing the database memory configuration
size, either through an update to the DATABASE_MEMORY
configuration parameter or an underlying area (eg.
SHEAPTHRES_SHR), DB2 does not immediately allocate a
corresponding amount of OS memory.  Rather, the memory is
allocated as required and needed for operations (even operations
such as a bufferpool increase will use any free existing
allocated memory before allocating any additional OS memory
needed).

This "deferred allocation" behaviour is intentional.  However,
there are some allocation paths, typically for small allocation
requirements, where the DB2 memory manager may only try to reuse
existing allocated memory, ignoring the possibility of
allocating new OS memory areas as permitted by the configuration
increase.  This can result in a wide variety of out of memory
messages (SQL0973, SQL0955, etc.).

The out of memory messages typically occur under an increased
fixed database memory limit or under a fixed instance memory
limit, where the automatic database memory size has
unnecessarily increased and exhausted instance memory.  The
unnecessary increase is due to allocating new OS memory under a
further database memory increase (rather than allocate new OS
memory under the increase that already occurred).

The easiest case to confirm is where a small allocation request
fails even though there is an abundance of "unreserved" memory.
For example, the db2diag.log entry for sqloMemLogPoolConditions
shows the following failure to allocate 16000 bytes, yet the
shared sort heap has only used 192GB out of 614GB configured,
and there is 109GB of unreserved left in the set.  There is no
obvious reason for the failure.

Out of memory failure for Shared Sort Heap (SHEAPTHRES_SHR) on
node 0.
Requested block size           : 16000 bytes.
Physical heap size             : 192185696256 bytes.
Configured heap size           : 614400000000 bytes.
Unreserved memory used by heap : 0 bytes.
Unreserved memory left in set  : 109930479616 bytes.

The immediate fix is to recycle the database.  During
activation, DB2 preallocates all OS memory based on the database
memory configured size, and the problem paths are avoided.
Problem Summary:
****************************************************************
* USERS AFFECTED:                                              *
* All DB2 systems                                              *
****************************************************************
* PROBLEM DESCRIPTION:                                         *
* See Error Description                                        *
****************************************************************
* RECOMMENDATION:                                              *
* Upgrade to DB2 Version 11.1 Mod 1 Fix Pack 2                 *
****************************************************************
Local Fix:
Recycle the database (force all applications, deactivate
database)
Solution
Workaround
N/A
BUG-Tracking
forerunner  : IT17904 
follow-up : 
Timestamps
Date  - problem reported    :
Date  - problem closed      :
Date  - last modified       :
04.08.2017
10.10.2017
10.10.2017
Problem solved at the following versions (IBM BugInfos)
Problem solved according to the fixlist(s) of the following version(s)