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 following formula provides an approximation of the number of pages required for the monitor heap: 
   (Memory used by applications            +
    Memory used by event monitors          +
    Memory used by monitoring applications +
    Memory used by Gateway applications)      / 4096

Memory used by each application

  • If the STATEMENT switch is off, zero
  • If the STATEMENT switch is on:
    • Add 400 bytes for each statement being run at the same time. (That is, the number of open cursors that an application might have). This is not the cumulative total of statements an application has run.
    • If a partitioned database, add the following for each statement:
      • 200 bytes * (average # of subsections)
  • If the application has issued sqleseti() info, add the sizes of the userid, applname, workstation name and accounting string.

Memory used by each event monitor

For each event monitor of type ACTIVITIES:
  • 3500 bytes
  • If the event monitor is for type TABLES, add 36K * (number of CPU cores + 1)
  • If the event monitor is for type FILE or PIPE, add 2K * (number of CPU cores + 1)
If you expect a heavy volume, add 250 megabytes for event records. Otherwise add a fraction that depends on the expected amount of work.
For each event monitor of type LOCKING or UOW:
  • 3500 bytes
  • 3K * (number of CPU cores + 1)
If you expect a heavy volume, add 250 megabytes for event records. Otherwise add a fraction that depends on the expected amount of work.

For each event monitor of the following type: DATABASE, TABLES, TABLESPACES, BUFFERPOOLS, CONNECTIONS, DEADLOCK:

  • 4100 bytes
  • 2 * BUFFERSIZE
  • If the event monitor is written to a file, add 550 bytes.
  • If the event monitor is for type DATABASE:
    • add 6000 bytes
    • add 100 bytes for each statement in the statement cache
  • If the event monitor is for type TABLES:
    • add 1500 bytes
    • add 70 bytes for each table accessed
  • If the event monitor is for type TABLESPACES:
    • add 450 bytes
    • add 350 bytes for each table space
  • If the event monitor is for type BUFFERPOOLS:
    • add 450 bytes
    • add 340 bytes for each buffer pool
  • If the event monitor is for type CONNECTIONS:
  • If an event monitor is of type DEADLOCK:
    • and the WITH DETAILS HISTORY is running:
      • add X*475 bytes times the maximum number of concurrent applications you expect to be running, where X is the expected maximum number of statements in your application's unit of work.
    • and the WITH DETAILS HISTORY VALUES is running:
      • also add X*Y bytes times the maximum number of concurrent applications you expect to be running, where Y is the expected maximum size of parameter values being bound into your SQL statements.

Memory used by each monitoring application

  • 250 bytes
  • For each database being reset:
    • 350 bytes
    • Add 200 bytes for each REMOTE database.
    • If the SORT switch is on, add 25 bytes.
    • If the LOCK switch is on, add 25 bytes.
    • If the TABLE switch is on:
      • add 600 bytes
      • add 75 bytes per table accessed
    • If the BUFFERPOOL switch is on:
      • add 300 bytes
      • add 250 bytes per table space accessed
      • add 250 bytes per buffer pool accessed
    • If the STATEMENT switch is on:
      • add 2100 bytes
      • add 100 bytes per statement
    • For each application connected to the database:
      • add 600 bytes
      • add 200 bytes for every REMOTE database the application is connected to
      • if the SORT switch is on, add 25 bytes
      • if the LOCK switch is on, add 25 bytes
      • if the BUFFERPOOL switch is on, add 250 bytes
  • For each DCS database being reset:
    • add 200 bytes for the database
    • add 200 bytes for each application connected to the database
    • if the STATEMENT switch is ON, Transmission level data must be reset:
      • for each database, add 200 bytes for each transmission level
      • for each application, add 200 bytes for each transmission level

Memory used by gateway applications

  • 250 bytes for each host database (even if all switches are off)
  • 400 bytes for each application (even if all switches are off)
  • If the STATEMENT switch is on:
    • For each application, add 200 bytes for each statement being run at the same time (That is, the number of open cursors that an application might have). This is NOT the cumulative total of statements an application has run.
    • Transmission level data must be accounted for:
      • for each database, add 200 bytes for each transmission level
      • for each application, add 200 bytes for each transmission level
  • If the UOW switch is on:
    • add 50 bytes for each application
  • For each application using a TMDB (for SYNCPOINT TWOPHASE activity):
    • add 20 bytes plus the size of the XID itself
  • For any application that has issued sqleseti to set client name, app name, wkstn or accounting:
    • add 800 bytes plus the size of the accounting string itself