| Database monitoring should be an ongoing, proactive process. Specialized monitoring software and traces can be used to monitor DB2. DB2 Performance Monitor and Omegamon IBM's DB2 Performance Monitor (PM) and Omegamon for DB2 are both analysis tools for the subsystem and applications. Their primary objective is to report DB2 instrumentation data in a form that is easy to understand and analyze. Both products present this instrumentation data in the following ways. The batch reports present the data you select in comprehensive reports or graphs containing systemwide and application-related information for both single DB2 subsystems and DB2 members of a data sharing group. You can combine instrumentation data from several DB2 locations into one report. Batch reports can be used to examine performance problems and trends over a period of time. The online monitor gives a current snapshot view of a running DB2 subsystem, including applications that are running. Its history function displays information about subsystem and application activity in the recent past. The statistics reports provide an excellent source of information, such as buffer pools, EDM pools, RID processing, and logging, all at a subsystem level. The accounting reports provide information about applications for specific time periods. Those are the most popular, most useful reports for ongoing analysis, trend analysis, and predictive monitoring.
More detailed reports, such as the lock detail analysis report for monitoring locking problems, require additional traces to be turned on and should be used only for problem analysis, not run on a continual basis. Both accounting and statistics reports have long and short versions. Which is used depends on the amount of detail needed for analysis. PM also includes user-tailored reports (UTRs) that allow you to tailor reports for more precise analysis. NOTE The DB2 PM product and Omegamon for DB2 will soon be merged into one product solution.
Resource Limit Facility DB2's resource limit facility, or governor, lets you perform the following activities: Set warning and error thresholds by which the governor can inform users, via your application programs, that a certain processing limit might be exceeded for a particular dynamic SELECT, INSERT, UPDATE, or DELETE statement. This is called predictive governing. Stop a currently executing dynamic SQL statement (SELECT, INSERT, UPDATE, or DELETE) that exceeds the processor limit that you have specified for that statement. This is sometimes called reactive governing to differentiate its function from that of predictive governing, a function that also is handled by the resource limit facility. The resource limit facility does not control static SQL statements, whether or not they are executed locally or remotely. Restrict bind and rebind activities to avoid performance impacts on production data. Restrict particular parallelism modes for dynamic queries.
|
