The performance impact of log reads is evident during a
rollback, restart, and database recovery.
About this task
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).
Db2 reads
the log records faster from the active log than from 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).
Procedure
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. If you
do not have enough space to maintain the archive data sets on disk,
consider using DFHSM to write the archive data sets to tape. This
method has a disadvantage in that HSM must read the archive data set
from disk in order to write it to tape, but the recall process is
improved for a number of reasons. You can pre-stage the recalls of
archive data sets in parallel (to striped data sets), and when the
data sets are recalled, parallel readers can proceed.
- Avoid device contention on the log data sets by placing
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 multiple concurrent readers access 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.
- In most cases, do not stripe active log data sets.
Important: Do not use striped active logs for disaster recovery.
You can use DFSMS to the stripe the logs, but striping is generally unnecessary with the latest devices. Striping increases the number of I/Os, which can increase CPU time and lead to potentially greater Db2 commit times. Striping might improve the performance of batch insert jobs, but it might also harm the performance of online transaction processing. Striping is especially risky for performance if you replicate the logs over long distances.