DB2 Version 9.7 for Linux, UNIX, and Windows
DB2 Version 9.7 for Linux, UNIX, and Windows
This parameter allows you to specify a string of up to 242 bytes to change the location where the log files are stored.
The string can point to either a path name or to a raw device. Note that as of DB2® Version 9, the use of raw devices for database logging is deprecated. As an alternative to using raw logs, you can use either direct input/output (DIO) or concurrent input/output (CIO).
If the string points to a path name, it must be a fully qualified path name, not a relative path name.
In a single or multi-partition DB2 ESE environment, the node number is automatically appended to the path. This is done to maintain the uniqueness of the path in multiple logical node configurations.
If you want to use replication, and your log path is a raw device, the overflowlogpath configuration parameter must be configured.
When the first new connection is made to the database, the database manager will move the logs to the new location specified by logpath.
There might be log files in the old log path. These log files might not have been archived. You might need to archive these log files manually. Also, if you are running replication on this database, replication might still need the log files from before the log path change. If the database is configured with the User Exit Enable (userexit) database configuration parameter set to Yes, and if all the log files have been archived either by DB2 automatically or by yourself manually, then DB2 will be able to retrieve the log files to complete the replication process. Otherwise, you can copy the files from the old log path to the new log path.
If logpath or newlogpath specifies a raw device as the location where the log files are stored, mirror logging, as indicated by mirrorlogpath, is not allowed. If logpath or newlogpath specifies a file path as the location where the log files are stored, mirror logging is allowed and mirrorlogpath must also specify a file path.
Recommendation: Ideally, the log files will be on a physical disk which does not have high I/O. For instance, avoid putting the logs on the same disk as the operating system or high volume databases. This will allow for efficient logging activity with a minimum of overhead such as waiting for I/O.
You can use the database system monitor to track the number of I/Os related to database logging.
The monitor elements log_reads (number of log pages read) and log_writes (number of log pages written) return the amount of I/O activity related to database logging. You can use an operating system monitor tool to collect information about other disk I/O activity, then compare the two types of I/O activity.
Do not use a network or local file system that is shared as the log path for both the primary and standby databases in a DB2 High Availability Disaster Recovery (HADR) database pair. The primary and standby databases each have copies of the transaction logs - the primary database ships logs to the standby database. If the log path for both the primary and standby databases points to the same physical location, then the primary and standby database would use the same physical files for their respective copies of the logs. The database manager returns an error if the database manager detects a shared log path.