Changes in TSM recovery log from TSMv6


Starting from TSMv6, the traditional recovery log has been divided into 4 logs to assist with the new DB2 database. The recovery log helps to ensure that a failure such as a system power outage or application error does not leave the database in an inconsistent state. The recovery log is essential when you restart the Tivoli Storage Manager or the database, and is required if you must restore the database.


Default TSM Recovery log mode

The recovery log mode for the Tivoli Storage Manager is the roll-forward mode. The recovery log stores data that is required to back up a restored database to the most recent committed transaction. You must have the most recent recovery logs to use the roll-forward mode. 


Changes to the database are recorded in the recovery log to maintain a consistent database image. You can restore the server to the latest time possible, by using the active and archive log files, which are included in database backups.

Also Read: How to increase or decrease TSM DB, active log and archive log size ?

To help ensure that the required log information is available for restoring the database, you can specify that the active log is mirrored to another file system location. For the best availability, locate the active log mirror on a different physical device

The role of the recovery log

When the logs that make up the recovery log are set up carefully, they work together to ensure that data is not lost.

The active log files contain information about in-progress transactions. This information is needed to restart the server and database after a disaster. Transactions are stored in the log files of the active log, and a transaction can span multiple log files.

When all transactions that are part of an active log file complete, that log file is copied from the active log to the archive log. Transactions continue to be written to the active log files while the completed active log files are copied to the archive log. If a transaction spans all the active log files, and the files are filled before the transaction is committed, the Tivoli® Storage Manager server halts.

When an active log file is full, and there are no active transactions referring to it, the file is copied to the archive log directory. An active log file cannot be deleted until all transactions in the log file are either committed or discontinued.

If the archive log is full and there is no failover archive log, the log files remain in the active log. If the active log then becomes full and there are in-progress transactions, the Tivoli Storage Manager server halts. If there is an archive failover log, it is used only if the archive log fills. It is important to monitor the archive log directory to ensure that there is space in the active log.



The Tivoli Storage Manager database manager can move active log files to the failover archive log. The database manager automatically manages the space that is available to the directories as database space. The database manager determines when database backups are required and automatically initiates them. 

When the database is backed up, the database manager deletes the archive log files that are no longer needed for future database backups or restores.

The archive log is included in database backups and is used for roll-forward recovery of the database. The archive log files that are included in a database backup are automatically pruned after a full database backup cycle has completed. Therefore, ensure that the archive log has enough space to store the log files for the database backups.

Recovery Log changes from TSM version 6

The purpose of recovery log is to help us to restore the DB to point in time if there is any disaster. When you issue a command to make changes, the changes are committed to the database to complete. A committed change is permanent and cannot be rolled back. If a failure occurs, the changes that were made but not committed are rolled back. Then all committed transactions, which might not have been physically written to disk, are reapplied and committed again. The recovery log consists of these logs:
  • Active log
  • Log mirror (optional)
  • Archive log
  • Archive failover log (optional)
During the installation process, you specify the directory location, the size of the active log, and the location of the archive logs. You can also specify the directory location of a log mirror if you want the additional protection of mirroring the active log. The amount of space for the archive logs is not limited, which improves the capacity of the server for concurrent operations compared to previous versions.

The space that you designate for the recovery log is managed automatically by the database manager program. Space is used as needed, up to the capacity of the defined log directories. You do not need to create and format volumes for the recovery log.

Ensure that the recovery log has enough space. Monitor the space usage for the recovery log to prevent problems.

To protect your data, locate the database directories and all the log directories on separate physical disks.

Active log

The active log files record transactions that are in progress on the server. The active log stores all the transactions that have not yet been committed. The active log always contains the most recent log records. If a failure occurs, the changes that were made but not committed are rolled back, and all committed transactions, which might not have been physically written to disk, are reapplied and committed again.

The location and size of the active log are set during initial configuration of a new or upgraded server. You can also set these values by specifying the ACTIVELOGDIRECTORY and the ACTIVELOGSIZE parameters of the DSMSERV FORMAT or DSMSERV LOADFORMAT utilities. Both the location and size can be changed later. 

Active log mirror

The active log mirror is a copy of the active log that can be used if the active log files cannot be read. All changes made to the active log are also written to the log mirror. There can be only one active log mirror.

Also Read: Different DSMADMC options to login to TSM Server

Mirroring the active log can protect the database when a hardware failure occurs on the device where the active log is stored. Mirroring the active log provides another level of protection in addition to placing the active log on hardware that has high-availability features. Creating a log mirror is optional but recommended. Place the active log directory and the log mirror directory on different physical devices. If you increase the size of the active log, the log mirror size is increased automatically. Mirroring the log can affect performance, because of the doubled I/O activity that is required to maintain the mirror. The additional space that the log mirror requires is another factor to consider.

You can create the log mirror during initial configuration of a new or upgraded server. If you use the DSMSERV LOADFORMAT utility instead of the wizard to configure the server, specify the MIRRORLOGDIRECTORY parameter. If the log mirror directory is not created at that time, you can create it later by specifying the MIRRORLOGDIRECTORY option in the server options file, dsmserv.opt.

Archive log

The archive log contains copies of closed log files that had been in the active log. The archive log is not needed for normal processing, but it is typically needed for recovery of the database.

To provide roll-forward recovery of the database to the current point in time, all logs since the last database backup must be available for the restore operation. The archive log files are included in database backups and are used for roll-forward recovery of the database to the current point-in-time. All logs since the last full database backup must be available to the restore function. These log files are stored in the archive log. The pruning of the archive log files is based on full database backups. The archive log files that are included in a database backup are automatically pruned after a full database backup cycle has been completed.

The archive log is not needed during normal processing, but it is typically needed for recovery of the database. Archived log files are saved until they are included in a full database backup. The amount of space for the archive log is not limited.

Archive log files are automatically deleted as part of the full backup processes and must not be deleted manually. Monitor both the active and archive logs. If the active log is close to filling, check the archive log. If the archive log is full or close to full, run one or more full database backups.

Also Read: SQL commands to query TSM Server

If the file systems or drives where the archive log directory and the archive failover log directory are located become full, the archived logs are stored in the active log directory. Those archived logs are returned to the archive log directory when the space problem is resolved, or when a full database backup is run.

You set the location of the archive log directory during initial configuration of a new or upgraded server. You can also specify the ARCHLOGDIRECTORY parameter of the DSMSERV FORMAT or DSMSERV LOADFORMAT utility. The location of the log can be changed later.

Archive failover log

The archive failover log, also called a secondary archive log, is the directory that the server uses to store archive log files when the archive log directory is full. Its use is optional but highly recommended.

Specifying an archive failover log directory can prevent problems that occur if the archive log runs out of space. Place the archive log directory and the archive failover log directory on different physical drives.

You can specify the location of the failover log directory during initial configuration of a new or upgraded server. You can also specify its location with the ARCHFAILOVERLOGDIRECTORY parameter of the DSMSERV FORMAT or DSMSERV LOADFORMAT utility. If it is not created through the utilities, it can be created later by specifying the ARCHFAILOVERLOGDIRECTORY option in the server options file, dsmserv.opt. 




What Others are Reading Now...

0 Comment to "Changes in TSM recovery log from TSMv6"

Post a Comment