DB2 10.5 for Linux, UNIX, and Windows
DB2 10.5 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.
If the string points to a path name, it must be a fully qualified path name, not a relative path name.
In both DB2 pureScale environments and DB2 Enterprise Server Edition environments, the database partition number and a log stream ID are automatically appended to the path, for example, /home/dbuser/dblogs/NODE0000/LOGSTREAM0000/.
In a DB2 pureScale environment, the first member connecting to or activating the database processes configuration changes to this log path parameter. The DB2 database manager verifies that the path exists and that it has both read and write access to that path. It also creates member-specific subdirectories for the log files. If any one of these operations fails, the DB2 database manager rejects the specified path and brings the database online using the old path. If the specified path is accepted, the new value is propagated to each member. If a member fails while trying to switch to the new path, subsequent attempts to activate it or to connect to it will fail (SQL5099N). All members must use the same log path.
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 to use log archiving and if all the log files have been archived either by the DB2 database system automatically or by yourself manually, then the DB2 database system 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 and will reduce additional processing time taken, such as when 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 corresponding copies of the logs. The database manager returns an error if the database manager detects a shared log path.