DB2® server
log file archiving is complicated by various operating-system file
handling and scheduling problems. For example, if a disk fails as
the DB2 database manager is
archiving a queue of log files, those log files and the transaction
data that they contain might be lost.
Correctly configuring database logging
can prevent these kinds of problems from undermining your availability
and recovery strategy.
The following general considerations apply to all methods of log archiving:
- The logarchcompr1 database
configuration parameter specifies whether the database manager compresses
log files that are contained in the location specified by logarchmeth1. If
the logarchmeth1 configuration parameter to a
value other than DISK, TSM, or VENDOR,
log archive compression has no effect regardless of the logarchcompr1 configuration
parameter setting.
- The logarchcompr2 database
configuration parameter specifies whether the database manager compresses
log files that are contained in the location specified by logarchmeth2. If
the logarchmeth2 configuration parameter to a
value other than DISK, TSM, or VENDOR,
log archive compression has no effect regardless of the logarchcompr2 configuration
parameter setting.
- The logarchmeth1 database
configuration parameter causes the database manager to archive log
files or to retrieve log files during rollforward recovery of databases
by using the method that you specify. A request to retrieve a log
file is made when the rollforward utility needs a log file that is
not found in the log path directory. Log files are archived from the
path that is specified by the logpath configuration
parameter.
The logarchmeth2 database configuration
parameter causes the database manager to archive additional copies
of log files. If you configure mirror logging, the log files that
are archived to the path that is specified by the logarchmeth2 parameter
are taken from the mirror log path. If you do not configure mirror logging,
the log files that are archived to the path that is specified by the logarchmeth2 parameter
are taken from the current log path.
- You should not use locally attached tape
drives to store log files if you are using any of the following features:
- Infinite logging
- Online recovery at the table space level
- Replication
- The asynchronous read log API (db2ReadLog)
- High availability disaster recovery (HADR)
Any of these features can cause a log file to be retrieved,
which can conflict with log archiving operations. Also, you cannot
use locally attached tape drives in a DB2 pureScale® environment
because the member that
is performing the log merge operation must retrieve logs for the other members.
- If you are using log archiving, the log manager attempts to archive
active logs as they are filled. In some cases, if a database is deactivated
before the log manager can record the archive as successful, the log
manager might try to archive the log again when the database is activated.
Thus, a log file can be archived more than once.
- If you use archiving, a log file is passed to the log manager
when it is full, even if the log file is still active and is needed
for normal processing. This process allows copies of the data to be
moved away from volatile media as quickly as possible. The log file
that is passed to the log manager is retained in the log path directory
until it is no longer needed for normal processing. At this point,
the disk space is reused.
- If a log file is archived and contains no
open transactions, the DB2 database
manager does not delete the file but renames it as the next log file
when such a file is needed. This process improves performance because creating a new
log file instead of renaming the file would require all pages to be
written out to guarantee that the necessary disk space or other storage
space is available. The
database manager retains up to 8 extra log files in the active log
path for renaming purposes.
- During crash recovery, during member crash
recovery (in a DB2 pureScale environment),
or during runtime rollback, the DB2 database
manager does not retrieve log files unless you set the logsecond database
configuration parameter to -1 (that is, if you enable infinite logging).
In a DB2 pureScale environment,
the database manager might have to retrieve archived logs during a
group crash recovery even if you do not enable infinite logging.
- Configuring log archiving does not guarantee rollforward recovery
to the point of failure but only attempts to make the failure window
smaller. As log files are filled, the log manager asynchronously archives
the logs. If the disk that contains the log fails before a log file
is filled, the data in that log file is lost. Also, because the files
are queued for archiving, the disk can fail before all the files are
copied, causing any log files in the queue to be lost.
To help
prevent the case where a failure of the disk or device on which the
log path is located causes log files to be permanently lost, you can
use the mirrorlogpath database configuration
parameter to ensure that the logs are written to a secondary path.
If the secondary path does not fail along with the primary disk or
device, the log files are available for recovery.
When you set both the mirrorlogpath and logarchmeth2 configuration
parameters, the logarchmeth2 configuration parameter
archives log files from the mirror log path instead of archiving additional
copies of the log files in the current log path. You can use this
log archiving behavior to improve resilience during rollforward recovery. The
reason is that a usable archived log file from the mirror log path
might still be available to continue a database recovery operation,
even if a primary log file from the current log path became corrupted
because of a disk failure before archiving.
- The configured size of each log file has a direct bearing on
log archiving. If each log file is very large, a large amount of data
can be lost if a disk fails. If you configure your database to use
small log files, the log manager archives the logs more frequently.
However, if you are moving the data to a slower device such as
tape, you might want to have larger log files to prevent the queue
from building up. Using larger log files is also recommended if archiving
each file requires substantial overhead, such as rewinding the tape
device or establishing a connection to the archive media.
- If you use log archiving, the log manager
attempts to archive primary logs as they are filled. In
some cases, the log manager archives a log before it is full. This
occurs if the log file is truncated because the database is deactivated,
you issue the ARCHIVE LOG command, the end of an
online backup is reached, or you issue the SET WRITE SUSPEND command.
Note: To free unused log space, a log file is truncated before it
is archived.
- If you are archiving logs and backup images
to a tape drive, you must ensure that the same tape drive is not the
destination for both the backup images and the archived logs. Because
some log archiving can take place while a backup operation is in progress,
an error can occur when the two processes are trying to write to the
same tape drive at the same time.
The following considerations apply to calling a user exit program
or a vendor program for archiving and retrieving log files:
- The DB2 database manager
opens a log file in read mode when it starts a user exit program to
archive the file. On some operating systems, this prevents the user
exit program from being able to delete the log file. Other operating
systems, such as the AIX® operating
system, allow processes, including the user exit program, to delete
log files. A user exit program should never delete a log file after
it is archived, because the file might still be active and needed
for crash recovery. The DB2 database
manager manages disk space reuse when it archives the log files.
- A user exit or vendor program might receive a request to archive
a file that does not exist, because there were multiple requests to
archive and the file was deleted after the first successful archiving operation. A
user exit or vendor program might also receive a request to retrieve
a file that does not exist, because it is located in another directory
or the end of the logs was reached. In both cases, the user exit or
vendor program should ignore this request and pass a successful return
code.
- On Windows operating
systems, you cannot use a REXX user exit to archive logs.
- The user exit or vendor program should allow for the existence
of different log files with the same name after a point-in-time recovery.
The user exit or vendor program should be written to preserve both
log files and to associate those log files with the correct recovery
path.
- If you enable a user exit or vendor program for two or more databases
that are using the same tape device to archive log files and a rollforward
operation is taking place on one of the databases, no other database should
be active. If another database tries to archive a log file while
the rollforward operation is in progress, one of the following situations
might occur:
- The logs that are required for the rollforward operation might
not be found.
- The new log file that is archived to the tape device might overwrite
the log files that were previously stored on that tape device.
To prevent either situation from occurring, you can take
one of the following steps:
- You can ensure that no other databases on the database partition
that calls the user exit program are open during the rollforward operation.
- You can write a user exit program to handle this situation.
DB2 Version 10.1 for Linux, UNIX, and Windows