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. |
