It 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 standby
The 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.