DB2 FOR LUW / DB2FORLUW / 970 - DB2

In rare scenarios, database activation or first connect may fail 
intermittently with SQL1084 or SQL1478 due to the requirement to 
allocate multiple shared memory segments in a contiguous address 
range. 
 
On UNIX, DB2 typically allocates the initial database memory 
configured size as a single shared memory segment.  In special 
cases, such as encountering the 256GB shared memory segment 
maximum on Linux, the initial allocation may be broken up into 
multiple smaller segments, which must be attached in a 
contiguous address range.  It cannot be assumed that a 
contiguous address range of the required size will always be 
available based on the address assigned to the first segment by 
the operating system. 
 
It is unlikely that database activation (with multiple shared 
segments) will fail directly after db2start as the db2sysc 
process address space has little fragmentation.  A possible 
scenario could involve multiple databases, where a database with 
a very large (eg. > 256GB) database memory footprint is 
deactivated (without shutting down the instance), and a second 
database is activated which is assigned some of the address 
range previously used by the very large footprint database. 
Upon reactivation, the memory for the very large database may 
try to get assigned to the remainder of the range, which would 
fail if there is some object or allocation mapped at the top of 
the range. 
 
Other possible scenarios exist, but again only in combination 
with the special case of an operating system limit preventing a 
single shared memory segment being used for the initial database 
memory allocation. 
 
Note that RHEL6 and SLES 11 use a top-down process address space 
layout.  It is a known problem that allocating a database memory 
size > 256GB will always fail in these environments - see APARs 
IC79948/IC79934 (9.7 FP6, 9.5 FP9 respectively).  The APARs will 
solve the basic problem of allocating contiguous segments in a 
top-down address layout model, but not the rarer intermittent 
conditions addressed by this APAR.

**************************************************************** 
* USERS AFFECTED:                                              * 
* Linux systems with database memory configurations exceeding  * 
* 256GB                                                        * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* See Error Description                                        * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* Upgrade to DB2 Version 9.7 Fix pack 7                        * 
****************************************************************

Any of: 
- recycle the instance with db2stop;db2start 
- limit database memory size to 250GB on Linux (allow a small 
amount of overhead to stay below the 256GB limit) 
- use "huge pages" on Linux for Database Memory

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
 

problem first fixed in DB2 Version 9.7 Fix Pack 7

not known / see Local fix

forerunner  : APAR is sysrouted TO one or more of the following: IC85660 
follow-up : 

Date  - problem reported    :
Date  - problem closed      :
Date  - last modified       :

14.03.2012
01.04.2013
01.04.2013

9.7.FP7