DB2 FOR LUW / DB2FORLUW / 950 - DB2

This issue impacts Linux systems running SLES 11 and RHEL 6 
which use a top-down process address space layout model. 
 
On a Linux AMD64 systems with available RAM > 256GB, DB2 might 
attempt creation of a shared memory segment with a size bigger 
then 256GB. The allocation fails because of the internal Linux 
limitation of the size of the shared memory segment with regular 
4k pages. 
In cases like that DB2 fails back to creation of many 1GB memory 
segments. The attempt of attaching to those segments may fail 
with an error in the db2diag.log like the following: 
 
2011-11-11-16.03.22.067021+000 E1756E494           LEVEL: Error 
(OS) 
PID     : 49511                TID  : 140737068918528PROC : 
db2sysc 0 
INSTANCE: db2inst1              NODE : 000          DB   : 
SAMPLE 
APPHDL  : 0-7                  APPID: 
*LOCAL.db2inst1.111111160322 
AUTHID  : db2inst1 
EDUID   : 26                   EDUNAME: db2agent (SAMPLE) 0 
FUNCTION: DB2 UDB, SQO Memory Management, 
sqloMemCreateSingleSegment, probe:100 
CALLED  : OS, -, shmget                           OSERR: EINVAL 
(22) 
 
2011-11-11-16.03.22.072365+000 E2251E781           LEVEL: Severe 
PID     : 49511                TID  : 140737068918528PROC : 
db2sysc 0 
INSTANCE: db2inst1              NODE : 000          DB   : 
SAMPLE 
APPHDL  : 0-7                  APPID: 
*LOCAL.db2inst1.111111160322 
AUTHID  : db2inst1 
EDUID   : 26                   EDUNAME: db2agent (SAMPLE) 0 
FUNCTION: DB2 UDB, SQO Memory Management, 
sqloGetSharedMemoryFromOs, probe:2028 
MESSAGE : ZRC=0x850F0005=-2062614523=SQLO_NOSEG 
          "No Storage Available for allocation" 
          DIA8305C Memory allocation failure occurred. 
DATA #1 : <preformatted> 
Unable to attach 387 segments totalling 415434866688 bytes 
starting at address 
0x0000000000000000.  One possible cause may be an improper 
setting for the 
shmmax Linux kernel tuneable. 
 
2011-11-11-16.03.22.072829+000 E3033E951           LEVEL: 
Warning 
PID     : 49511                TID  : 140737068918528PROC : 
db2sysc 0 
INSTANCE: db2inst1              NODE : 000          DB   : 
SAMPLE 
APPHDL  : 0-7                  APPID: 
*LOCAL.db2inst1.111111160322 
AUTHID  : db2inst1 
EDUID   : 26                   EDUNAME: db2agent (SAMPLE) 0 
FUNCTION: DB2 UDB, base sys utilities, 
sqeLocalDatabase::FirstConnect, probe:100 
MESSAGE : ZRC=0x850F0005=-2062614523=SQLO_NOSEG 
          "No Storage Available for allocation" 
          DIA8305C Memory allocation failure occurred. 
DATA #1 : String, 299 bytes 
Failed to allocate the desired database shared memory set. 
The configured DATABASE_MEMORY plus desired overflow may have 
exceeded INSTANCE_MEMORY or the maximum shared memory on the 
system. 
Attempting to start up with a smaller overflow allowance. 
Desired database shared memory set size is (bytes): 
DATA #2 : unsigned integer, 8 bytes 
415434801152

**************************************************************** 
* USERS AFFECTED:                                              * 
* Users allocating shared memory > 256GB                       * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* During memory allocation at database startup, when we fall   * 
* back to allocating smaller segments, we can fail to attach   * 
* to one of those segments which will fail the whole           * 
* allocation.                                                  * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* Upgrade to DB2 Version 9.5 Fix Pack 9                        * 
****************************************************************

A workaround on SLES 11 / RHEL 6 is to update the Linux kernel 
parameter vm.legacy_va_layout=1 prior to issuing db2start.  This 
will revert to the "bottom-up" address layout used prior to SLES 
11 / RHEL 6.  In this case multiple segments can be attached 
contiguously upwards.  Fragmentation can still be an issue, 
however (see APAR IC82029)

DB2 Version 9.5 Fix Pack 9 for Linux, UNIX, and Windows
 DB2 Version 9.5 Fix Pack 10 for Linux, UNIX, and Windows
 

First fixed in DB2 Version 9.5 Fix Pack 9

keiner bekannt / siehe Local-Fix

Vorgänger  : APAR is sysrouted TO one or more of the following: IC79948 IC84158 
Nachfolger : 

Datum - Problem gemeldet    :
Datum - Problem geschlossen :
Datum - der letzten Änderung:

22.11.2011
27.03.2012
27.03.2012

9.5.FP9