Memory requirements for monitor data

The memory required for monitor data is allocated from the monitor heap. Monitor heap size is controlled by the mon_heap_sz database configuration parameter. This parameter has a default value of AUTOMATIC, meaning that the monitor heap can increase as needed until the instance_memory limit is reached.

If you configure the mon_heap_sz parameter manually, consider the following factors:

  • The number of monitoring applications
  • The number and nature of event monitors
  • The monitor switches set
  • The level of database activity
Consider increasing the value for the mon_heap_sz parameter if monitor commands fail with an SQLCODE of -973.
The amount of monitor heap being used can be seen using the MON_GET_MEMORY_POOL table function: 
SELECT *
  FROM TABLE(MON_GET_MEMORY_POOL('DBMS',NULL,-1))MEM
 WHERE MEMORY_POOL_TYPE = 'MONITOR'
There are many situations where monitor heap is used:
  • All active event monitors consume monitor heap. Every fast writer (db2fw) thread and event monitor (db2evm) thread uses monitor heap.
  • Active ACTIVITIES, LOCKING, PACKAGE CACHE, UNIT OF WORK, STATISTICS, THRESHOLD VIOLATIONS and CHANGE HISTORY event monitors allocate event records from monitor heap. The number of allocated records is included in the Queue Manager Info portion of the output of db2pd -gfw. On busy systems where you expect a heavy volume to be recorded by these event monitors, the Current Number of Records increases quickly. On less busy systems, it increases more slowly depending on the expected amount of work.
  • Each application's past activities (those completed in the current unit of work) are allocated from monitor heap. This occurs in the following situations:
    • When a LOCKING event monitor is active and HISTORY collection is enabled
    • When a DEADLOCKS WITH DETAILS HISTORY event monitor is active
  • Routine data is stored in monitor heap when MON_RTN_DATA is enabled.
  • Executable list data is stored in monitor heap when MON_UOW_EXECLIST is enabled.
  • Monitor usage list data is stored in monitor heap.
  • Any monitor switch that is turned ON consumes monitor heap.
  • Each monitor application using SNAPSHOT, SWITCH and RESET interfaces consumes monitor heap. In these situations, monitor heap is used to hold switch and resettable data until the monitor application detaches from the instance.
  • Each database connection consumes monitor heap when the STATEMENT switch is turned on. In these situations, monitor heap is used to hold monitoring data for currently running statements.
  • An application's client information, set through the sqleseti() api or through the WLM_SET_CLIENT_INFO procedure, is stored using monitor heap.
  • On a Db2 Connect gateway, database and application information is stored in monitor heap. If the statement switch is ON, currently running statements store information in monitor heap.