Which exception fields and threshold values to choose

You can choose from a comprehensive set of exception fields and it can be difficult to decide which ones to choose and which threshold values to specify for your site. As a rule, most sites only need to define a limited number of thresholds.

To get started with exception reporting, consider using the sample Exception Threshold data set member RKO2DATA(DGOETV51), which contains a selection of predefined exception thresholds. For more information, see Exception Threshold data set.

In general, long response times are a good indicator of a performance problem and therefore you should start by defining exception thresholds for time fields.

To use exception processing efficiently, consider what the most important applications or transactions in your system are. Always define exception thresholds for critical business applications. In addition, frequently executed applications are good candidates for exception thresholds.

The application-specific thresholds are defined by specifying the plans for which the threshold applies. An efficient way of determining which plans or connection IDs should be the focus of exception reporting is to produce Accounting TOP lists.

You can use the performance objectives stated in your service level agreement as a starting point. Accounting TOP lists and TOP ONLY reports are good references when determining which threads to monitor with exception processing. You can modify the predefined threshold values and specify additional exception fields.

Carefully consider the fields for which to specify exception thresholds. The more fields you specify, the greater the effects on processing.

You can use the exception profiling method and a sample of your installation's DB2 instrumentation data to calculate threshold values for exception fields. For more information, see Exception profiling.