3.1 TSM V7 Database and recoverylog overview and functions

 TSM V7.1 Database and Recoverylog Overview & Functions

The server uses the Tivoli Storage Manager database to manage information about client files. The Tivoli Storage Manager recovery log ensures that the database is consistent and available. Starting from TSM V6, DB2 database is used for server transactions.

Tivoli Storage Manager Database (DB2)

The Tivoli Storage Manager database contains information that is needed for server operations and information about client data that is backed up, archived, and space-managed. The database does not store client data. Instead, the database points to the locations of the client files in the storage pools. The database includes the following information

• Client nodes and administrators

• Policies and schedules

• Server settings

• Locations of client files on server storage

• Directory structures

• Server operations, for example, activity logs and event records

If the database is unusable, the entire Tivoli Storage Manager server is unavailable. If the database is lost and cannot be recovered, all of the data that the server manages is lost. Therefore, it is imperative that the server and database are protected.

After you install a new server or upgrade an existing database, you run an offline utility command to initialize the database and recovery log. You run DSMSERV FORMAT for a new server. You run DSMSERV LOADFORMAT when upgrading to a new database. Both of these utilities initialize the active and archive logs and optionally initialize the archive fail over log and mirror of the active log.

Tivoli Storage Manager V7 database features

Automatic statistics collection: Automatic statistics collection helps to improve database performance by collecting up-to-date table statistics.

Automatic database reorganization: Automatic reorganization of the database tables is done based on the statistics gathered.

SQL queries: You can get information from the server database with full-function SQL queries. The database makes more sophisticated SQL queries on the data possible. To use some of the capabilities, you might require more advanced SQL skills to develop new tools.

Database audits: Audits on the database run automatically as needed to ensure consistency. Separate audits that might be long-running are not needed.

Database buffer size: The database manager automatically adjusts the values for several memory configuration parameters that are based on requirements of the workload of the system.

Note:

• You can continue to manage the server database by using Tivoli Storage Manager administrative interfaces. You do not require the skills of a database administrator.

• Although the Tivoli Storage Manager database is running on DB2, it is designed especially for Tivoli Storage Manager.

• You need to manage the database with Tivoli Storage Manager utilities. If you have DB2 experience, you can use DB2 utilities to only monitor the database.

• Do not alter the DB2 software that is installed with Tivoli Storage Manager installation packages and fix packs. Do not install or upgrade to a different version, release, or fix pack of DB2 software because doing so can damage the database.

• The TSM server requires that you install and use the DB2 V10.5 that is packaged with the Tivoli Storage Manager server. No other version of DB2 can exist on the system.

From TSM V7, TSM has DB2 version 10. The DB2 V10.x database for Tivoli Storage Manager manages information about client files located in storage pools and provides for the other server components. The database contains, among other things

• Access control information for administrative clients

• Information about registered client nodes

• Policies and schedules

• The activity log and event records

• Information about Tivoli Storage Manager volumes

• Data storage inventory

• Encryption key

• Deduplication index

• Disaster recovery plans

Tivoli Storage Manager Recovery log

The recovery log helps ensure that a sudden failure does not leave the database in an inconsistent state. The recovery log is also necessary for restoring the database. All changes to the database since the last database backup are saved in the recovery log. With roll-forward mode and an intact recovery log, you can recover the database up to its most current state, the point at which the database was lost. The recovery log keeps all transactions since the last database backup. Frequent database backups reduce recovery log storage requirements. After a full backup finishes, recovery log records that precede the backup are deleted.

The recovery log consists of the following logs

Active log: The active log stores all the transactions that are not yet committed. The active log always contains the most recent log records.

Archive log: The archive log is a closed and stored copy of the previous active log. Archived log files are stored until they are included in a database backup. This log is not needed for normal processing, but it is needed to recover the database.

Archive failover log: The archive failover log is the directory that the server uses to store archive log files that cannot be stored in the archive log directory.

Log mirror: The log mirror is a duplicate copy of the active log. All changes that are made to the active log are also written to the log mirror. Having the log mirror for the active log can protect the database from a hardware failure that affects the active log. Place the log mirror on a different physical device.

Changes to the database are recorded in the recovery log for maintaining a consistent database image. The recovery log includes updates to information that can include the following activities

• Defining a management class

• Backing up a client file

• Registering a client node

For the best availability and protection, you can specify that active logs are mirrored. You should locate those mirror logs on a separate physical device.

Monitoring the Database and Recovery log

• Monitor the database and log space and the file systems where the directories are located to ensure that space is always available.

• Use the QUERY DB command to examine information about the database.

• Use the QUERY DBSPACE command to view information about the storage space defined for the database, such as total space, used space, and free space.

• Use the format=detail parameter to show more detailed information.

• Use the QUERY LOG command for obtaining information on the log. The same information is available when the Tivoli Storage Manager server is offline. Issue the DSMSERV DISPLAY LOG command.

Tivoli Storage Manager Transaction

A transaction is the unit of work exchanged between the Tivoli Storage Manager client and Tivoli Storage Manager server. The server holds transaction log records in a buffer pool until they are written to the recovery log to support multiple transactions from concurrent client sessions. When the transaction is committed.The log records that transaction to the active recovery log, then the  Tivoli Storage Manager database is updated.

Tivoli Storage Manager provides a TXNGROUPMAX server option. Use this option to specify the number of files or directories that are contained within a transaction group. The default option is 4096 objects.

Changes resulting from transactions are in the buffer pool temporarily and not made to the database immediately. Therefore, the database and recovery log are not always consistent. When all records for a transaction are written to the recovery log, Tivoli Storage Manager updates the database. The transaction is then committed to the database. At some point after a transaction is committed, the server deletes the transaction record from the recovery log.

When a transaction occurs, the Tivoli Storage Manager server does the following actions

• Reads a database page into the database buffer and updates it. A page is a 16 KB block that is transferred as a unit between memory and disk storage.

• Writes a transaction log record to the recovery log to describe the action that is occurring and associates it with the database page. This action is a precaution in case the database page needs to be rolled back during recovery.

• Writes the database page to the database, releasing it from the buffer pool. The page remains in the buffer pool until buffer space is needed for another page.

• A transaction containing more than one file or directory is a transaction group. Tivoli Storage Manager provides a TXNGROUPMAX server option that lets you specify the number of files or directories that a transaction group contains. You can affect the performance of client backup, archive, restore, and retrieve operations by using a larger value for the TXNGROUPMAX option.

• You can use the TXNGROUPMAX option to increase performance when Tivoli Storage Manager writes to tape. This performance improvement can be considerable when a user transfers multiple small files.

• Be sure to monitor the effects on the recovery log if you increase the value of TXNGROUPMAX by a large amount. The larger value can increase utilization of the recovery log, and increase the length of time for a transaction to commit.

[facebook src="Uptodatewithme" width="500" height="400" hide-cover="true" posts="true"/]