Log archiving in an HADR environmentIt is recommended that both the
primary database and the standby databases be configured for log archiving, as
any of these systems could be promoted to become the primary at which point it
will be required to archive its log files.

Only the current primary
database can perform log archiving. If the primary and standby databases are
set up with separate archiving locations, logs are archived only to the primary
database's archiving location. In the event of a takeover, the standby database
becomes the new primary database and any logs archived from that point on are
saved to the original standby database's archiving location. In such a
configuration, logs are archived to one location or the other, but not both;
with the exception that following a takeover, the new primary database might
archive a few logs that the original primary database had already archived. In
a multiple standby system, the archived log files can be scattered among all
databases' (primary and standbys) archive devices. A shared archive is
preferred because all files are stored in a single location.

Many operations need to
retrieve archived log files. These operations include: database roll forward,
the HADR primary database retrieving log files to send to the standby database
in remote catch up, and replication programs (such as Q Replication) reading
logs. As a result, a shared archive for an HADR system is preferred, otherwise,
the needed files can be distributed on multiple archive devices, and user
intervention is needed to locate the needed files and copy them to the
requesting database. The recommended copy destination is an archive device. If
copying into an archive is not feasible, copy the logs into the overflow log
path. As a last resort, copy them into the log path (but one should be aware
that there is a risk of damaging the active log files). DB2® does not auto
delete user copied files in the overflow and active log path, so one should
manually remove the files when they are no longer needed by any HADR standby or
any application.Log file management on standbyThe standby
database automatically manages log files in its log path. The standby database
does not delete a log file from its local log path unless it has been notified
by the primary database that the primary database has archived it. This
behavior provides added protection against the loss of log files. If the
primary database fails before the log file is safely stored in the archive, the
standby database would ensure the log file is archived. If both the
logarchmeth1 and logarchmeth2 configuration parameters are in use, the standby
database does not recycle a log file until the primary database has archived it
using both methods.