Planning for periodic monitoring
Periodic monitoring serves to check system throughput, used resources (processor, I/Os, and storage), changes to the system, and significant exceptions that might affect system performance during peak periods when constraints and response-time problems are more pronounced.
About this task
A typical periodic monitoring interval of about ten minutes
provides information on the workload achieved, resources used, and
significant changes to the system. In effect, you are taking snapshots
at
peak loads and under normal conditions.
The current peak is also a good indicator of the future average. You might have to monitor more frequently at first to confirm that expected peaks correspond with actual ones. Do not base conclusions on one or two monitoring periods, but on data from several days representing different periods.
You might notice that subsystem response is becoming increasingly sluggish, or that more applications fail from lack of resources (such as from locking contention or concurrency limits). You also might notice an increase in the processor time Db2 is using, even though subsystem responses seem normal. In any case, if the subsystem continues to perform acceptably and you are not having any problems, Db2 might not need additional tuning.
Procedure
To monitor peak periods:
- Db2 for z/OS®
- z/OS
- The transaction manager (IMS, CICS®, or WebSphere®)
- Db2 Connect
- IBM Data Server Driver for JDBC and SQLJ
- The network
- Distributed application platforms (such as Windows, UNIX, or Linux®)
To compare the different results from each source, monitor each for the same period of time. Because the monitoring tools require resources, you need to consider the overhead for using these tools as well.