Determining when and how long to collect

When you use ISPF or a batch job to collect data, you can specify whether data should be collected immediately or at a specific time, and you can specify whether a collect task should stop after an elapsed time or after a number of records are collected.

The decision when to start and stop a collect task depends on the system load, the intended usage of the data, and the purpose of the analysis. The following scenarios provide some ideas:
  • To collect summary information (data type Summary) of the buffer pool performance over a day, you can start collecting data at midnight (start time) and run the job for 24 hours (elapsed time), but only take samples of 10 seconds every 60 minutes (continuity). You can also combine data from multiple collect tasks and use the accumulated data as input when you create reports. This might be helpful to detect trends over a longer period or regular peaks.

    Note that DB2® updates data that is used for summary information at so-called statistics intervals. Also, most statistics counters are incremental counters. To report a valid counter value for a given period, the difference between the latest and earliest counter value is computed. This means that a collect task should cover at least a statistics interval to produce meaningful summary information. The sampling duration, here 10 seconds, is long enough to capture any updates made by Db2.

  • To collect detailed information (data type Detail) during peak times in your organization's business, which might be around 11:00 a.m. and 3:00 p.m., you can start two collect tasks through ISPF, one at 10:30 and one at 2:30 p.m. (start times). Each task can collect data for an hour (elapsed time) and take samples every 10 minutes for five seconds (continuity).

    Note that detail information in activity reports is based on actual counts of events, opposed to summary information. You can keep a collect task as short as required without loosing accurateness. More details are described in Preliminary remarks about the accuracy of summary and detail reports.

  • If you must analyze the cause of a current performance problem, you can start a collect task immediately (start time) and run it for 45 minutes (elapsed time) to collect summary data. This step might be followed by a second step that collects detailed data for a shorter time.
  • If you need to collect data to perform an optimization or simulation (both are described in detail in the following topics), for example to tune a subsystem or peak load periods, you need to identify the peak load periods and collect a representative mean of trace data from this time.
  • The collection of data can also serve multiple purposes. For example, if you need to perform an optimization of object placements and a simulation (before you apply any changes to a system), you collect data continuously for approximately 20 minutes during a defined system load period. Simulation requires the record format Short, the data type Detail, and a continuous collection of data, but these specifications serve as well the requirements for an optimization.

The important point is that the collection of data (what, when, and how) must always be performed with regard to the intended usage of this data. Buffer Pool Analyzer can analyze and report performance data, but inadequate selection of trace data might lead to wrong conclusions. For successful tuning, you should understand that the results of an analysis are always based on workload at the time trace data was collected. Other workloads, which run at other times, may have different results. If you plan to optimize the buffer pool usage, you should carefully determine which workload you consider representative for your optimization.