Previous Topic: Simulating Access with TestsNext Topic: DB2 Traces


Monitoring

It is critical to design for performance when building applications, databases, and SQL statements. You have designed the correct SQL, avoided programmatic joins, clustered commonly accessed tables in the same sequence, and have avoided inefficient repeat processing. Your application may be in production and running without problems, but there is still more you can do to increase its performance.

Which statement is the most expensive? Is it the tablespace scan that runs once per day, or the matching index scan running millions of times per day? Are all your SQL statements sub-second responders that do not need tuning? Which statement is the number one consumer of CPU resources? All of these questions can be answered by monitoring your DB2 subsystems and the applications that access them.

DB2 provides facilities for monitoring the behavior of the subsystem, as well as the applications that are connected to it. This feature is achieved primarily though the DB2 trace facility. DB2 has several different types of traces.