Log mirroring

IBM® DB2 server supports log mirroring at the database level. Mirroring log files helps protect a database from accidental deletion of an active log and data corruption caused by hardware failure.

If you are concerned that your active logs might be damaged (as a result of a disk crash), consider using the mirrorlogpath configuration parameter to specify a secondary path for the database to manage copies of the active log, mirroring the volumes on which the logs are stored.

The mirrorlogpath configuration parameter allows the database to write an identical second copy of log files to a different path. It is recommended that you place the secondary log path on a physically separate disk (preferably one that is also on a different disk controller). That way, the disk controller cannot be a single point of failure.

When you first give a value to the mirrorlogpath configuration parameter, DB2 will not use it until the next database startup. This behavior is similar to the newlogpath configuration parameter.

If there is an error writing to either the active log path or the mirror log path, the database marks the failing path as "bad", writes a message to the administration notification log, and writes subsequent log records only to the remaining "good" log path. DB2® does not attempt to use the "bad" path again until the current log file is either full or truncated. When DB2 needs to open the next log file, it verifies that this path is valid, and if so, begins to use it. If not, DB2 does not attempt to use the path again until the next log file is accessed for the first time. There is no attempt to synchronize the log paths, but DB2 keeps information about access errors that occur, so that the correct paths are used when log files are archived. If a failure occurs while writing to the remaining "good" path, the database shuts down.