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.
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 ?
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.
Also Read: Starting TSM server in maintenance mode
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.
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
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
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.
0 Comment to "Changes in TSM recovery log from TSMv6"
Post a Comment