|
Problem IC78855
|
Status: Closed |
MEMORY LEAK IN APPLICATION HEAP IF MONITOR UDFS RETURN NO DATA |
| product: |
DB2 FOR LUW / DB2FORLUW / 970 - DB2 |
| Problem description: |
If a monitor table function returns no rows it will leak
application heap memory. Since the memory leak is in
application heap memory it is freed up when the application
terminates. Therefore this is really an issue for long running
applications rather than short running applications.
The following table functions are susceptible to this memory
leak:
MON_GET_APPL_LOCKWAIT
MON_GET_BUFFERPOOL
MON_GET_CONNECTION
MON_GET_CONNECTION_DETAILS
MON_GET_CONTAINER
MON_GET_EXTENT_MOVEMENT_STATUS
MON_GET_FCM
MON_GET_FCM_CONNECTION_LIST
MON_GET_INDEX
MON_GET_LOCKS
MON_GET_MEMORY_POOL
MON_GET_MEMORY_SET
MON_GET_PKG_CACHE_STMT
MON_GET_PKG_CACHE_STMT_DETAILS
MON_GET_SERVICE_SUBCLASS
MON_GET_SERVICE_SUBCLASS_DETAILS
MON_GET_TABLE
MON_GET_TABLESPACE
MON_GET_UNIT_OF_WORK
MON_GET_UNIT_OF_WORK_DETAILS
MON_GET_WORKLOAD
MON_GET_WORKLOAD_DETAILS
WLM_GET_ACTIVITY_DETAILS
WLM_GET_CONN_ENV
WLM_GET_QUEUE_STATS
WLM_GET_SERVICE_CLASS_AGENTS
WLM_GET_SERVICE_CLASS_AGENTS_V97
WLM_GET_SERVICE_CLASS_WORKLOAD_OCCURRENCES
WLM_GET_SERVICE_CLASS_WORKLOAD_OCCURRENCES_V97
WLM_GET_SERVICE_SUBCLASS_STATS
WLM_GET_SERVICE_SUBCLASS_STATS_V97
WLM_GET_SERVICE_SUPERCLASS_STATS
WLM_GET_WORK_ACTION_SET_STATS
WLM_GET_WORKLOAD_OCCURRENCE_ACTIVITIES
WLM_GET_WORKLOAD_OCCURRENCE_ACTIVITIES_V97
WLM_GET_WORKLOAD_STATS
WLM_GET_WORKLOAD_STATS_V97
The following administrative views are also susceptible to this
memory leak:
SYSIBMADM.MON_BP_UTILIZATION
SYSIBMADM.MON_CONNECTION_SUMMARY
SYSIBMADM.MON_CURRENT_SQL
SYSIBMADM.MON_CURRENT_UOW
SYSIBMADM.MON_DB_SUMMARY
SYSIBMADM.MON_LOCKWAITS
SYSIBMADM.MON_PKG_CACHE_SUMMARY
SYSIBMADM.MON_SERVICE_SUBCLASS_SUMMARY
SYSIBMADM.MON_TBSP_UTILIZATION
SYSIBMADM.MON_WORKLOAD_SUMMARY |
| Problem Summary: |
****************************************************************
* USERS AFFECTED: *
* Anybody using monitor table functions *
****************************************************************
* PROBLEM DESCRIPTION: *
* If any of the listed monitoring table functions don't return *
* any data, processing fails to release storage that had been *
* allocated to hold the result set output. Over time such *
* occurrences will cause Application Heap usage to rise. *
****************************************************************
* RECOMMENDATION: *
* Upgrade to Verison 9.7 Fix Pack 6. *
**************************************************************** |
| Local Fix: |
recycle any monitoring application with a persistent connection
in order to release the memory. The connection can also be
forced via "force application". |
| available fix packs: |
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
|
| Solution |
Problem was first fixed in Version 9.7 Fix Pack 6 |
| Workaround |
not known / see Local fix |
| BUG-Tracking |
forerunner : APAR is sysrouted TO one or more of the following: IC83659
follow-up : |
| Timestamps |
Date - problem reported :
Date - problem closed :
Date - last modified :
| 21.09.2011
09.05.2012
01.06.2012 |
| Problem solved at the following versions (IBM BugInfos) |
9.7.FP6
|
| Problem solved according to the fixlist(s) of the following version(s) |
| 9.7.0.6
|
 |
