IBM BPM, V8.0.1, All platforms > Tuning > Advanced tuning > Database: DB2 for z/OS specific tuning
Size log files appropriately
To improve log write performance, size log files appropriately.
The following guidelines apply:
- Choose a large size for OUTPUT BUFFER size
- The OUTPUT BUFFER field of installation panel DSNTIPL lets you specify the size of the output buffer used for writing active log data sets. The maximum size of this buffer (OUTBUFF) is 400 000 KB. Choose as large a size as your system can tolerate to decrease the number of forced I/O operations that occur because there are no more buffers. A large size can also reduce the number of wait conditions.
- Choose fast devices for log data sets
- The devices assigned to the active log data sets must be fast ones. Because of its very high sequential performance, ESS can be used in environments where the write activity is high to avoid logging bottlenecks.
- Avoid device contention
- Place the copy of the bootstrap data set and, if using dual active logging, the copy of the active log data sets, on volumes that are accessible on a path different than that of their primary counterparts.
- Preformat new active log data sets
- Whenever you allocate new active log data sets, preformat them using the DSNJLOGF utility described in the DB2 Utility Guide and Reference. This action avoids preformatting the log, which normally occurs at unpredictable times.
Active logs are reused only after the active log has been archived using the DB2 automatic archiving process.
During a rollback, restart, and database recovery, the performance impact of log reads is evident. DB2 must read from the log and apply changes to the data on disk. Every process that requests a log read has an input buffer dedicated to that process. DB2 searches for log records in the following order:
- Output buffer
- Active log data set
- Archive log data set
If the log records are in the output buffer, DB2 reads the records directly from that buffer.
If the log records are in the active or archive log, DB2 moves those log records into the input buffer used by the reading process (such as a recovery job or a rollback).
It is always fastest for DB2 to read the log records from the active log rather than the archive log. Access to archived information can be delayed for a considerable length of time if a unit is unavailable or if a volume mount is required (for example, a tape mount).
To improve log read performance:
- Archive to disk: If the archive log data set resides on disk, it can be shared by many log readers. In contrast, an archive on tape cannot be shared among log readers. Although it is always best to avoid reading archives altogether, if a process must read the archive, that process is serialized with anyone else who must read the archive tape volume.
For example, every rollback that accesses the archive log must wait for any previous rollback work that accesses the same archive tape volume to complete.
- Avoid device contention on the log data sets: Place your active log data sets on different volumes and I/O paths to avoid I/O contention in periods of high concurrent log read activity.
When there are multiple concurrent readers of the active log, DB2 can ease contention by assigning some readers to a second copy of the log. Therefore, for performance and error recovery, use dual logging and place the active log data sets on a number of different volumes and I/O paths. Whenever possible, put data sets within a copy or within different copies on different volumes and I/O paths. Ensure that no data sets for the first copy of the log are on the same volume as data sets for the second copy of the log.
- Stripe active log data sets: The active logs can be striped using DFSMS. Striping is a technique to improve the performance of data sets that are processed sequentially. Striping is achieved by splitting the data set into segments or stripes, and spreading those stripes across multiple volumes. Striping can improve the maximum throughput log capacity and is most effective when there are many log records between commits. Striping is useful if you have a high I/O rate for the logs. Striping is needed more with ESCON channels than with the faster FICON channels.