DB2 FOR LUW / DB2FORLUW / 970 - DB2

When a query is compiled, the executable form of the query is 
called a section. In a DPF database, the section may get 
logically divided into subsections, where each subsection gets 
executed within it's own agent thread. 
When this query is invoked, there are a set of steps that will 
distribute the section into those subagents.  There are various 
internal memory areas that are used in order to perform this 
operation of distributing the section into each subagent. 
Further, when a query is done executing, the sections will be 
cached in memory so that they can be re-used quickly.  The 
internal memory areas associated with the section remain 
allocated to facilitate fast section re-use and is good for 
performance. 
However, a logic problem exists that is unique to a situation 
where the database is both DPF, and INTRA_PARALLEL is on. 
When a section get's re-used in this scenario, there exists a 
faulty codepath that may assign some internal memory without 
first checking if it already exists.  This results in 
overwriting the memory address for the previous allocation 
without first freeing it.  Because of this, over a period of 
time when hitting this codepath, the memory allocations in this 
area will continue to increase, and this is the perceived memory 
leak.

Problem Description: 
MEMORY LEAK IN APPLICATION SHARED MEMORY IF INTRA_PARALLEL IS ON 
AND THE INSTANCE IS DPF. 
Problem Summary: 
When a query is compiled, the executable form of the query is 
 
called a section. In a DPF database, the section may get 
logically divided into subsections, where each subsection gets 
executed within it's own agent thread. 
When this query is invoked, there are a set of steps that will 
distribute the section into those subagents.  There are various 
internal memory areas that are used in order to perform this 
operation of distributing the section into each subagent. 
Further, when a query is done executing, the sections will be 
cached in memory so that they can be re-used quickly.  The 
internal memory areas associated with the section remain 
allocated to facilitate fast section re-use and is good for 
performance. 
However, a logic problem exists that is unique to a situation 
where the database is both DPF, and INTRA_PARALLEL is on. 
When a section get's re-used in this scenario, there exists a 
faulty codepath that may assign some internal memory without 
first checking if it already exists.  This results in 
overwriting the memory address for the previous allocation 
without first freeing it.  Because of this, over a period of 
time when hitting this codepath, the memory allocations in this 
area will continue to increase, and this is the perceived memory 
leak.

n/a

DB2 Version 9.7 Fix Pack 2 for Linux, UNIX, and Windows
 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 9a 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 10 for Linux, UNIX, and Windows
 

Problem is first fixed in Version 9.7 Fix Pack 2

n/a

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

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

08.10.2009
13.05.2010
13.05.2010

9.7.FP2