Determining what to collect

By making certain specifications, you can determine what data should be collected.

When you collect data with ISPF, or prepare a batch job to collect data, you can determine what to collect by specifying:

A record format, which determines whether Standard or Short header information from each IFCID record is collected.
Standard includes all IFCID record header information, which allows you to create more sophisticated reports from the collected data (inclusion of associated information, better aggregation and presentation, and better sorting).

Short includes only part of the IFCID record header information, which minimizes the amount of collected data and is appropriate when collecting large amounts of data.
A data type, which determines whether Summary or Detail data is collected.
The data type affects the content. Summary and Detail are the base for the corresponding summary and detail reports.

Technically, Summary collects buffer pool statistics (IFCID 2), data set statistics (IFCID 199), and buffer pool characteristics (IFCID 202) data. Detail additionally collects buffer pool activity data (IFCIDs 6, 7, 8, 9, 10, and 198). Note that especially IFCID 198 can cause noticeable overhead to a system during the collection of trace data. (It records the page requests Getpage, Set write intend, and Release page being sent to the DB2® Buffer Manager.)

Beginning with Buffer Pool Analyzer Version 2, the group buffer pool related IFCIDs 230, 251, and 254 are collected in addition to a subsystem's buffer pool related IFCIDs. If the Db2 subsystem from which performance data is collected is a member of a data sharing group, summary reports contain several additional topics with group buffer pool specific performance information. The collection of group buffer pool specific trace data and its inclusion in activity reports is performed automatically and remains hidden to you. Interpreting activity reports describes also the group buffer pool specific details, including the IFCIDs from which this data is derived.

Besides the technical aspect of what is collected, Summary and Detail data require further distinction regarding dynamic availability of current data. Both types of data are provided and recorded by Db2. Detail data is recorded by Db2 at the time an activity occurs. This means that the activity counts of the associated IFCIDs are current. However, summary data is recorded by Db2 at so-called statistics intervals. The interval value is a DB2 subsystem parameter, with a default setting of 1 minute (or the value specified as STATIME in DSNZPARM). This means that statistics records are to be written at the end of this interval. Beginning with DB2 10, the STATIME subsystem parameter applies only to IFCIDs 0105, 0106, 0199, and 0365. IFCIDs 0001, 0002, 0202, 0217, 0225, and 0230 are no longer controlled by STATIME, and the corresponding trace records are written at fixed, one-minute intervals. In addition, another Db2 subsystem parameter (specified as SYNCVAL in DSNZPARM) can be set to determine whether the recording and update is synchronized with some part of the hour, for example, 15, 30, 45 minutes past the hour (no synchronization is the default). The consequence for collecting summary data is that you need to consider also for how long you collect data. As a rule of thumb, assuming that you do not know the STATIME and SYNCVAL parameter settings, the time should span two default statistics intervals. Usually, one hour is a reliable choice to obtain meaningful summary reports from collected data.
A continuity, which determines for how long trace data is collected and whether it is collected continuously or in regular intervals (for example, every 30 minutes for 40 seconds). The basic rules are:
- Continuous collection of data simplifies matters and is recommended when the overhead to a system is negligible (for example, when you collect summary data).
- Collection in regular intervals is recommended to minimize the overhead to a system or to minimize the amount of data being collected (for example, when you collect Detail data on a heavily used system).

Your specifications for record format, data type, and continuity are highly dependent on the intended usage of collected data, as outlined in Table 1 and the following topics.

Table 1. Intended usage of collected data and recommended specifications of record format, data type, and continuity
Intended usage	Record format	Data type	Continuity
On the host: To create summary reports	`Short` or `Standard`	`Summary`	Continuously to analyze activity during a certain time (for example, between 10:00 a.m. and 12:00 a.m.), or in intervals to analyze the performance of longer periods (for example, every 60 minutes for 60 seconds for all day long).
On the host: To create detail reports	`Short` or `Standard` If sophisticated reports are not required, use `Short` for overhead reasons.	`Detail`	As required, but should be limited to reduce overhead (IFCID 198).
On the host: To create buffer pool data files for use on the client	Format, type, and continuity is determined by the client-based functions that require bpd files as input. See further entries.
On the client: To view performance data This function uses bpd files as input.	`Short` is sufficient.	`Detail`	Continuously, or in intervals to analyze the performance of longer periods.
On the client: To optimize object placements and buffer pool sizes This function uses bpd files as input.	`Short` is sufficient.	`Detail` is recommended.	Continuously or in intervals, depending on the goal of the optimization.
On the client: To perform simulations This function uses raw trace data as input.	`Short` is required. Simulation does not use extended IFCID header information. Further, this minimizes the amount of collected data and the system overhead.	`Detail`	Continuous collection is required, for approximately 20 minutes (subject to system load and the amount of collected data).
On the client: To analyze the long-term performance of buffer pools This function uses bpd files as input.	`Short` is sufficient.	`Detail` is recommended.	As available, because this function usually uses existing bpd files as input.