home clear 64x64
en blue 200x116 de orange 200x116 info letter User
suche 36x36
Neueste VersionenFixList
11.1.0.7 FixList
10.5.0.9 FixList
10.1.0.6 FixList
9.8.0.5 FixList
9.7.0.11 FixList
9.5.0.10 FixList
9.1.0.12 FixList
Haben Sie Probleme? - Kontaktieren Sie uns.
Kostenlos registrieren anmeldung-x26
Kontaktformular kontakt-x26

DB2 - Problembeschreibung

Problem IC70644 Status: Geschlossen

MEMORY LEAK IN DATABASE HEAP ON HADR STANDBY DATABASE EACH TIME A NEW LOG
FILE IS CREATED.

Produkt:
DB2 FOR LUW / DB2FORLUW / 970 - DB2
Problembeschreibung:
A memory leak occurs in Database Heap on HADR standby database. 
This memory leak happens at a data structure used by log file 
management on standby database. This data structure is allocated 
when a new log file is created. But, it is not freed after 
using. Fortunately, this data structure will be reused if its 
corresponding log file is reused. 
 
So, this memory leak can be triggered by LOGARCHMETH1 = 
LOGRETAIN, since log files will not be reused. 
 
Database Heap memory usage can be monitored by one of the 
following methods: 
- db2pd -db <database> -mempools   (monitor the "dbh" pool) 
- database snapshot 
- select POOL_ID, POOL_CUR_SIZE, POOL_WATERMARK from 
sysibmadm.snapdb_memory_pool where POOL_ID = 'DATABASE' 
 
If this memory leak exists, you can observe a memory usage 
increase by 2096 bytes for every new log file. You can use db2pd 
to monitor memory usage of this data structure. 
 
  db2pd -d <standby db name> -memb sort 2 
 
Here is a sample output: 
======================== 
Memory blocks sorted by size for dbh pool: 
PoolID   PoolName TotalSize(Bytes) TotalCount LOC File 
...... 
2        dbh      16768            8          74  418710486 
 
Please note that the file 418710486 is your target to monitor. 
"TotalCount" means how many data structures allocated, and still 
not released. 
"TotalSize(Bytes)" means how many bytes occupied by this data 
structure. 
You can see that "TotalSize(Bytes) / TotalCount = 2096" and both 
of them keep rising along with new log files being created.
Problem-Zusammenfassung:
**************************************************************** 
* USERS AFFECTED:                                              * 
* ALL                                                          * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* A memory leak occurs in Database Heap on HADR standby        * 
* database.                                                    * 
* This memory leak happens at a data structure used by log     * 
* file management on standby database. This data structure is  * 
* allocated when a new log file is created. But, it is not     * 
* freed after using. Fortunately, this data structure will be  * 
* reused if its corresponding log file is reused.              * 
*                                                              * 
* So, this memory leak can be triggered by                     * 
* LOGARCHMETH1=LOGRETAIN, since log files will not be reused.  * 
*                                                              * 
* Database Heap memory usage can be monitored by one of the    * 
* following methods:                                           * 
* - db2pd -db <database> -mempools  (monitor the "dbh" pool)   * 
* - database snapshot                                          * 
* - select POOL_ID, POOL_CUR_SIZE, POOL_WATERMARK from         * 
* sysibmadm.snapdb_memory_pool where POOL_ID = 'DATABASE'      * 
*                                                              * 
* If this memory leak exists, you can observe a memory usage   * 
* increase by 2096 bytes for every new log file. You can use   * 
* db2pd to monitor memory usage of this data structure.        * 
*                                                              * 
* db2pd -d <standby db name> -memb sort 2                      * 
*                                                              * 
* Here is a sample output:                                     * 
* ========================                                     * 
* Memory blocks sorted by size for dbh pool:                   * 
* PoolID  PoolName TotalSize(Bytes) TotalCount LOC File        * 
* ......                                                       * 
* 2        dbh      16768            8          74  418710486  * 
*                                                              * 
* Please note that the file 418710486 is your target to        * 
* monitor.                                                     * 
* "TotalCount" means how many data structures allocated, and   * 
* still not released.                                          * 
* "TotalSize(Bytes)" means how many bytes occupied by this     * 
* data structure.                                              * 
* You can see that "TotalSize(Bytes) / TotalCount = 2096" and  * 
* both of them keep rising along with new log files being      * 
* created.                                                     * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* Update to version 9.7 fixpack 4 or later.                    * 
****************************************************************
Local-Fix:
Set log archive method to other methods, instead of LOGRETAIN. 
Alternatively, if you have chance to restart your standby 
database, the memory will be freed.
verfügbare FixPacks:
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 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

Lösung
This problem is first fixed in version 9.7 fixpack 4.
Workaround
keiner bekannt / siehe Local-Fix
Bug-Verfolgung
Vorgänger  : APAR is sysrouted TO one or more of the following: IC70802 IC70803 
Nachfolger : 
Weitere Daten
Datum - Problem gemeldet    :
Datum - Problem geschlossen :
Datum - der letzten Änderung:
18.08.2010
28.04.2011
28.04.2011
Problem behoben ab folgender Versionen (IBM BugInfos)
9.7.FP4
Problem behoben lt. FixList in der Version
9.7.0.4 FixList