Reviewing the Rules for an Effective Monitoring Strategy

DB2 has a reputation of being easy for users to understand; they specify what data to retrieve, not how to retrieve it. The layer of complexity removed for the users, however, had to be relegated elsewhere: to the code of DB2.

DB2 also has a reputation as a large resource consumer. This reputation is largely because of DB2's complexity. Because DB2 performance analysts must understand and monitor this complexity, they require an array of performance monitoring tools and techniques. Part IV outlines the majority of these tools. (Refer to Chapter 39, "Components of a Total DB2 Solution," for information on third-party performance monitoring tools and Appendix B for a listing of third-party tool vendors .)

To review, an effective monitoring strategy includes the following:

• Scheduled batch performance monitor jobs to report on the recent performance of DB2 applications and the DB2 subsystem

• An online monitor that executes when DB2 executes to enable quick monitoring of performance problems as they occur

• Online monitors for all teleprocessing environments in which DB2 transactions execute (for example, CICS, IMS/TM, or TSO)

• Regular monitoring of z/OS for memory use and VTAM for network use

• Scheduled reports from the DB2 Catalog and queries run against the RTS tables

• Access to the DB2 DSNMSTR address space to review console messages

• Use of the DB2 -DISPLAY command to view databases, threads, and utility execution

Part V delves into tuning the performance of DB2.