DB2 - Problembeschreibung
Problem IC77375 | Status: Geschlossen |
APPLICATION SHARED MEMORY (APPSHRH) MIGHT LEAK WHEN ADDING ROWS TO MDC TABLES. | |
Produkt: | |
DB2 FOR LUW / DB2FORLUW / 970 - DB2 | |
Problembeschreibung: | |
Application shared memory (appshrh) might leak when inserting rows to MDC tables. This symptom could be perceived by virtue of "db2pd -db <db_name> -memblocks top". The memblock will increase %Bytes and/or %Count even after the insert commits or the application terminates. 1st Round: Top memory consumers in AppCtl memory set: PoolID PoolName TotalSize(Bytes) %Bytes TotalCount %Count LOC File 20 appshrh 100904064 93.40 788313 72.06 3450 1560397958 2nd Round: Top memory consumers in AppCtl memory set: PoolID PoolName TotalSize(Bytes) %Bytes TotalCount %Count LOC File 20 appshrh 143394048 95.33 1120266 79.21 3450 1560397958 3rd Round: Top memory consumers in AppCtl memory set: PoolID PoolName TotalSize(Bytes) %Bytes TotalCount %Count LOC File 20 appshrh 479587200 98.43 3746775 92.31 3450 1560397958 When an insert into an MDC table occurs, the composite block index is probed for the logical cell corresponding to the dimension values of the record to be inserted. To improve the performance of a transaction inserting multiple rows into an MDC, a cache of cell values is maintained to quickly find the target cell for the next insert without having to probe the composite block index. The allocated memory should be freed at the end of a transaction or when an application terminates. But there is a problem where DB2 does not free the entire list. | |
Problem-Zusammenfassung: | |
**************************************************************** * USERS AFFECTED: * * All users * **************************************************************** * PROBLEM DESCRIPTION: * * Application shared memory (appshrh) might leak when * * inserting rows to MDC tables. * * * * * * This symptom could be perceived by virtue of "db2pd -db * * <db_name> -memblocks top". The memblock will increase * * %Bytes and/or %Count even after the insert commits or the * * application terminates. * * * * 1st Round: * * Top memory consumers in AppCtl memory set: * * PoolID PoolName TotalSize(Bytes) %Bytes TotalCount * * %Count LOC File * * 20 appshrh 100904064 93.40 788313 * * 72.06 3450 1560397958 * * * * 2nd Round: * * Top memory consumers in AppCtl memory set: * * PoolID PoolName TotalSize(Bytes) %Bytes TotalCount * * %Count LOC File * * 20 appshrh 143394048 95.33 1120266 * * 79.21 3450 1560397958 * * * * 3rd Round: * * Top memory consumers in AppCtl memory set: * * PoolID PoolName TotalSize(Bytes) %Bytes TotalCount * * %Count LOC File * * 20 appshrh 479587200 98.43 3746775 * * 92.31 3450 1560397958 * * * * When an insert into an MDC table occurs, the composite block * * index is probed for the logical cell corresponding to the * * dimension values of the record to be inserted. To improve * * the performance of a transaction inserting multiple rows * * into an MDC, a cache of cell values is maintained to quickly * * find the target cell for the next insert without having to * * probe the composite block index. * * * * The allocated memory should be freed at the end of a * * transaction or when an application terminates. But there is * * a problem where DB2 does not free the entire list. * **************************************************************** * RECOMMENDATION: * * Upgrade to DB2 version 9.7.0.5. * **************************************************************** | |
Local-Fix: | |
Restart the database to free the leaked memory in appshrh. | |
verfügbare FixPacks: | |
DB2 Version 9.7 Fix Pack 5 for Linux, UNIX, and Windows | |
Lösung | |
The problem has been fixed in DB2 9.7.0.5. | |
Workaround | |
keiner bekannt / siehe Local-Fix | |
Weitere Daten | |
Datum - Problem gemeldet : Datum - Problem geschlossen : Datum - der letzten Änderung: | 06.07.2011 07.12.2011 07.12.2011 |
Problem behoben ab folgender Versionen (IBM BugInfos) | |
9.7.0.5 | |
Problem behoben lt. FixList in der Version | |
9.7.0.5 |