Understanding Tivoli Storage Manager Version 6 and 7 recovery log behavior

Answer

Summary:

The Tivoli Storage Manager recovery log (transaction log) is used to maintain database concurrency when there are multiple database read or write operations happening at the same time (database transactions).

These transactions are managed external of the Tivoli Storage Manager application with the introduction of the DB2 database back-end in Tivoli Storage Manager V6.1.

The recovery log works by tracking in-flight database transactions as they occur in sequential order. The oldest transaction is always the "pinning" transaction. A transaction is no longer a "pinning" as soon as it is completed and closed. The operation that generated the transaction is in control of when the transaction begins and when it ends.

DB2 manages database transactions using a ROLLFORWARD method, meaning that completed database transactions are committed to the database only when a full database backup occurs.

To accommodate the ROLLFORWARD method, the recovery log needs to be configured during initial Tivoli Storage Manager implementation. The related Tivoli Storage Manager recovery log options are as follows:

Tivoli Storage Manager option:	Option Description
ACTIVELOGDIRECTORY	Specifies active log file location.
ACTIVELOGSIZE	Specifies the size of the active log.
ARCHLOGDIRECTORY	Specifies the archive log location.
MIRRORLOGDIRECTORY	Specifies the mirror log file location.
ARCHFAILOVERLOGDIRECTORY	Specifies the archive log failover file location.

Planning and implementing:

It is important to properly plan and implement each of these options to ensure server stability. Review the following documents:

• Capacity Planning
• Configuring the server for optimal performance

• Capacity Planning
• Configuring the server for optimal performance

• Capacity Planning
• Configuring the server for optimal performance

• Capacity Planning
• Configuring the server for optimal performance

• Capacity Planning
• Configuring the server for optimal performance

Option details:

ACTIVELOGDIRECTORY (required) - Specifies the location on a file system where the DB2 active logs will exist.

• Used for storing in-flight transactional data.
• Fixed size (meaning if you specify it to be 2 GB it will use 2 GB of space on the file system, regardless of whether there are transactions within the log or not).
• Non-circular log type is used.
• Can be changed in the dsmserv.opt file (requires server restart).

ACTIVELOGSIZE (required) - Specifies the size of the active log.

• The default size is 2 GB in Version 6.1 and 16 GB in later versions. The maximum supported value is 128 GB in 6.1, 6.2, and 6.3. The maximum supported value is 512 GB in 7.1+.
• For V6, active log files are created using 512 MB sized files. The number of logs created is determined by the size of the active log specified divided by 512. The size specified is rounded up to the next even number. For V7, the above is true up to 128 GB, but the size of each active log file increases to 1GB for values over 128GB.
• Can be changed in the dsmserv.opt file (requires server restart).

ARCHLOGDIRECTORY (required) - Specifies the location on a file system where the DB2 archive logs will exist.

• Used for rollfoward recovery.
• Stores historical completed transactions between full database backups.
• When a single active log file is full and complete, it is archived to this location from the ACTIVELOGDIRECTORY. The log files in this location are removed after a full database backup.
• Non-fixed size (meaning file system utilization can fluctuate, depending on server activity)
• Can be changed in the dsmserv.opt file (requires server restart).

MIRRORLOGDIRECTORY (optional) - Specifies the location on a file system where DB2 will mirror the active log.

• This parameter is optional, but recommended.
• Fixed size.
• In V6, mirror log files are created using 512 MB sized files. The number of logs created is determined by the size of the active log divided by 512. If you specified an odd number with the ACTIVELOGSIZE option, the value is rounded up to the next even number. For V7, the above is true up to 128 GB, but the size of each mirror log file increases to 1GB for ACTIVELOGSIZE values over 128GB.
• Can be changed in the dsmserv.opt file (requires server restart).

ARCHFAILOVERLOGDIRECTORY (optional) - Specifies the location on a file system where DB2 archive logs can be written in the event that the archive log directory is full or unavailable.

• If DB2 is unable to archive a log file to the archive log directory, it will attempt to move it to the archive failover directory. The log files in this location are removed after a full database backup.
• Non-fixed size.
• Can be changed in the dsmserv.opt file (requires server restart).

Example Initial Layout:



In this particular example ( Figure A ), only an active log and archive log have been defined. Each resides on its own file system. The active log size is set to 2048 MB within the Tivoli Storage Manager options file. This means there will be four 512 MB active log files at all times. These four files are generated upon the first invocation of the server (first start of DB2). Note that there is about 1 GB of free space in active log file system for temporary log movements in this example, but we recommend 8 GB of free space for production servers. The archive log file system is 10 GB in size, and currently is empty. The archive log file system utilization will increase as server workload increases.

Example log movement

As the Tivoli Server Manager server completes work, transactions are inserted sequentially by timestamp into the active log. The first transaction to begin is written to the first active log file (ie S0000001.LOG). The QUERY LOG command can be used to determine actual active log utilization (as well as utilization of the other log types). Once an active log file is full, and all of the transactions within it are complete, it is archived (by moving the file) to the archive log location (Figure B ). A new active log file, sequentially named S0000005.LOG is created in the active log location to replace the archived S0000001.LOG log file (Figure C ).



Logs continue to be archived as they become full and complete, causing the archive log directory utilization to increase over time (Figure D ). To clear the archive logs, a full database backup is required (two full database backups may be required at server levels below 6.1.4.1 and 6.2.2.0). After a full database backup has been completed, the archive log directory will empty (Figure E ). Note that this is an oversimplified example, and one or two archive log files might still exist after a backup.




Best practices and additional notes:

• The database, active log, archive log, mirror log, and archive log fail over should reside, at minimum, on separate file systems. Neither the active log, nor the database, should reside on disk shared for any other operations. Further disk planning and layout recommendations can be found in the "Configuring the server for optimal performance" section as referenced above.
• The active log file system should have at least 8 GB of free space after the fixed active logs have been generated.
• If the active or archive log file systems fill to 100% utilization, the database manager will stop, causing a Tivoli Storage Manager outage. The active log file system should not regularly fluctuate in utilization, but the archive log file system will. Monitoring of the archive log file system is suggested.
• Tivoli Storage Manager monitors the archive log file system utilization. By default, the server will attempt to initiate a full database backup when it becomes 80% utilized in an attempt to remove archive logs and lower the file system utilization. This threshold value can be changed with the ARCHLOGUSEDTHRESHOLD option.
• If the active log utilization within Tivoli Storage Manager (viewable with the QUERY LOG command) reaches 100%, the server will stop. DB2 does attempt to automatically cancel long running transactions, but is not always successful before the log is exhausted.
• A long running transaction can prevent active logs from being archived. Diagnostics to identify long running transactions are available. Contact support for assistance.