News
Abstract
This document will explain the risk and impact of running a Database Monitor trace (STRDBMON).
Content
DBMON traces can be resource intensive and cause severe performance problems on the system. To limit the risk, use the JOB parameter to narrow the jobs traced to as few as possible. Using JOB (*ALL) should be avoided. In fact, avoid any combination of name, user, and number on the JOB parameter that would cause a large number of jobs to be traced. If JOB(*ALL) or many jobs must be traced, understand the potential impact that this may have on the system.
Considerations:
1. Jobs that the DBMON is started over will require more CPU cycles than normal when executing queries (OPNQRYF, SQL , Query/400, etc.).
2. Specifying additional filters on the STRDBMON command won't avoid all resource overhead when the filter criteria isn't met. The monitor will still require additional resource usage in the monitored jobs while the monitor is active.
3. The system writes the collected data to a database file which will require additional disk IO and disk space. The database monitor output file can become a bottleneck if the volume of activity being traced is high.
4. The system must also communicate with all jobs selected in the monitor at both the start and end of the collection. This communication to the monitored jobs can cause an increase in activity at both the end and start of the collection.
5. System wide resources are used to start, end and monitor the jobs. Monitors can affect more jobs in the system than those that are part of the monitor.
Type of monitors (from least resource cost to most):
Private monitor - JOB(*) or JOB(nnnnnn/user/name) - with or without filters.
Private monitor - JOB(*) or JOB(nnnnnn/user/name) - with or without filters.
Only the specific job is affected with additional CPU cycles and writing to the outfile.
Public monitor - JOB(*ALL/QUSER/QRWTSRVR), JOB (*ALL/QUSER/QZDASOINIT), JOB(*ALL/*ALL/job_name), JOB(*ALL/user/job_name), JOB(*ALL/user_profile/generic*) - with or without additional filters.
All jobs meeting the JOB criteria are affected. The degree of overhead depends on the number of jobs involved and volume of SQL being generated. Additional CPU cycles and writing to the outfile can be significant if the number of jobs and volume of SQL are significant.
Public monitor - JOB(*ALL/*ALL/*ALL) - with or without additional filters.
ALL jobs are affected. The degree of overhead depends on the number of jobs involved and volume of SQL being generated. Additional CPU cycles and writing to the outfile can be significant if the number of jobs and volume of SQL are significant.
It is IBM's recommendation to make the database monitor as specific as possible to reduce the potential resource (performance) impact. A private monitor is best. Beyond that, scope the monitor to as few jobs as possible. Use filters to further reduce resource impact. However, starting and ending the monitor should be coordinated with operations due to potential performance or resource impacts. Coordinating the monitor with operations will ensure that the monitor can be ended quickly if there are issues.
To see what monitors maybe running refer to the following document:
https://www-01.ibm.com/support/docview.wss?uid=nas8N1010823
[{"Type":"MASTER","Line of Business":{"code":"LOB57","label":"Power"},"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SWG60","label":"IBM i"},"Platform":[{"code":"PF012","label":"IBM i"}],"Version":"7.4.0"}]
Was this topic helpful?
Document Information
Modified date:
10 August 2020
UID
ibm10882914