|
Problem IC67389
|
Status: Closed |
SCAN SHARING FOR MDC BLOCK INDEX SCAN CAUSES MEMORY LEAK ON DBHEAP. |
| product: |
DB2 FOR LUW / DB2FORLUW / 970 - DB2 |
| Problem description: |
The database heap might keep growing like as below:
Memory for database: SAMPLE
utilh pckcacheh other catcacheh bph (6)
bph (5)
192.0K 51.1M 192.0K 2.1M 158.1M
398.9M
bph (4) bph (3) bph (2) bph (1) bph (S32K)
bph (S16K)
203.6M 315.9M 1.6G 610.4M 832.0K
576.0K
bph (S8K) bph (S4K) shsorth lockh dbh
apph (29148)
448.0K 384.0K 2.1M 44.0M 18.3G
64.0K
'db2pd -db <dbname> -memb' command shows number of specific
memory blocks keep growing, and the blocks share major part of
dbheap.
Please look LOC (700) and File (1232204724) to identify this
problem.
PoolID PoolName TotalSize(Bytes) TotalCount LOC
File
2 dbh 883638912 531033 700
1232204724
The memory blocks are allocated by scan sharing functionality to
hold a key of block index scan. DB2 has a code path which does
not free the memory blocks even if the database retains no scan
sharing sets. |
| Problem Summary: |
****************************************************************
* USERS AFFECTED: *
* Users who use IXSCAN for MDC block indexes. *
****************************************************************
* PROBLEM DESCRIPTION: *
* The database heap might keep growing like as below:Memory *
* for database: SAMPLEutilh pckcacheh other catcacheh *
* bph (6) bph (5)192.0K 51.1M 192.0K 2.1M *
* 158.1M 398.9Mbph (4) bph (3) bph (2) bph (1) bph *
* (S32K) bph (S16K)203.6M 315.9M 1.6G 610.4M *
* 832.0K 576.0Kbph (S8K) bph (S4K) shsorth lockh *
* dbh448.0K 384.0K 2.1M 44.0M 18.3G'db2pd -db *
* <dbname> -memb' command shows number of specificmemory *
* blocks keep growing, and the blocks share major partof *
* dbheap.Please look LOC (700) and File (1232204724) to *
* identify thisproblem.PoolID PoolName TotalSize(Bytes) *
* TotalCount LOC File2 dbh 883638912 *
* 531033 7001232204724The memory blocks are allocated by *
* scan sharingfunctionality tohold a key of block index scan. *
* DB2 has a code path whichdoesnot free the memory blocks even *
* if the database retains noscansharing sets. *
****************************************************************
* RECOMMENDATION: *
* Please upgrade to DB2 V9.7 fixpack 2 or later. *
**************************************************************** |
| Local Fix: |
Users can disable scan sharing by using optimizer profiles. |
| available fix packs: |
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 8 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 9a 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
|
| Solution |
Problem was first fixed in Version 9.7 Fix Pack 2. |
| Workaround |
not known / see Local fix |
| BUG-Tracking |
forerunner : APAR is sysrouted TO one or more of the following: IC67521
follow-up : |
| Timestamps |
Date - problem reported :
Date - problem closed :
Date - last modified :
| 23.03.2010
08.07.2010
08.07.2010 |
| Problem solved at the following versions (IBM BugInfos) |
9.7.FP2
|
| Problem solved according to the fixlist(s) of the following version(s) |
| 9.7.0.2
|
 |
