Primary Storage

 View Only

Tivoli Storage Manager V6.x Best Practices Deployment Guide

By Archive User posted Thu October 27, 2011 07:02 PM


Originally posted by: csd_tuc

Tivoli Storage Manager Version 6 first GA'd in 2009 with a new internal database, our highest levels of scalability and availability, and new data reduction features such as deduplication at the source and target.  Along the way, we published "Deployment Recommendations for TSM v6 Server" to streamline customers' deployment planning and experience, greatly improving time to value for clients.  The Deployment Guide is a living document with "real time" updates occurring whenever new insights are discovered in areas such as installation, configuration, or resource allocation.  Client feedback suggests this document has greatly improved their deployment experience, resulting in quality metrics that have consistently meet or beat pre-v6 standards.  

You can find the latest version of the Deployment Guide at this link:

Be sure to refer back to the document link from time to time to see what is changed, new insights, and recommendations to make TSM V6 deployment a success.

Below, I've copied the the October 2011 version below for your reference. 



How do I successfully deploy a Tivoli Storage Manager V6.1, V6.2, or V6.3 server?


The Tivoli Storage Manager version 6 servers delivered many significant changes to the architecture of the product. The most notable change is the replacement of the proprietary embedded database with the IBM Db2 database. Because of the scope and magnitude of these changes, there are new and changed considerations for deploying a Tivoli Storage Manager server compared to what was needed for previous releases.


The following topics discuss aspects of planning for, and successfully deploying, a Tivoli Storage Manager V6.1, V6.2, or V6.3 server. This document will be updated periodically. Refer back to this document from for the latest recommendations. The date published is displayed with this document and is updated when it is republished.

Critical changes in database protection and recovery
System requirements
Recovery log - sizing to support the workload
Database Operations
Upgrading from V5 to V6
Deduplication effects on operations and resources
Renaming a server
Operating system and hardware problems and workarounds

Critical changes in database protection and recovery
The following are specific differences with Tivoli Storage Manager V6.1 and V6.2 that represent differences in capability or administration that must be considered.

Back to top

System requirements

The published memory requirements for the Tivoli Storage Manager V6.1 server specify the minimum possible that can be used. For example, the RAM requirement is specified as 2 GB for testing and 4 GB for production. However, a system that has 4 GB of RAM is appropriate only for a small production server. A server is considered to be small if it has the following characteristics:

Memory requirements for larger production servers are expected to be more than the 4 GB minimum that is documented. The memory recommendations for a production server running Tivoli Storage Manager V6.1 depend on the architecture:

For production servers, 64-bit architecture is preferred and recommended. The 32-bit platform, which is supported for Windows only, has constrained memory and therefore might not be suitable for large production use.

The available system paging space may also need to be reviewed and set to a higher value to support one or more Tivoli Storage Manager V6 servers running on the system. Review the following for recommendations and guidance on setting the paging space appropriately:


Note that the memory and system requirements for V6.2 specify higher recommended values than were specified for V6.1.

Back to top


The installation tools used for Tivoli Storage Manager V6.1 and V6.2 manage installation of the product along with any required upgrades of existing installed product resources. Review the following topic for guidance, recommendations, and known issues for installation:


For additional considerations about upgrading an existing Tivoli Storage Manager V5.x server, see
Upgrading from V5 to V6.

Back to top


The Tivoli Storage Manager servers are limited by operational concerns similar to those that were encountered for V5. While the database and recovery log sizes can be much larger in V6 than was possible in V5, the operational limits will still dictate how large a server may be or the total workload it can support. The operational limits of a server vary based on workload, server deployment (system, CPU, memory, I/O bandwidth), and risk tolerance of an organization (recovery objectives for the Tivoli Storage Manager server itself).

The operational limits to consider are:

The key item to consider is that over a given period of time, usually 24 hours, many different tasks need to be accomplished. These tasks support the client workloads by storing data or retrieving it and returning it to the client when requested. These tasks keep the server environment healthy and take appropriate steps for disaster recovery of the server.

The Tivoli Storage Manager development team continues to evaluate the limits of the product. Some key limitations to consider are:

Back to top

Recovery log - sizing to support the workload

Tivoli Storage Manager uses a database to record information about server policies, registered nodes, data stored on the server and other attributes that must be tracked. To preserve the integrity and consistency of the records in the database, Tivoli Storage Manager has always used a transaction log. In earlier versions of the product, there was a single log (comprising one or more physical volumes) used for this purpose. The maximum log size available for earlier versions of the product was approximately 13 GB. With Tivoli Storage Manager V6.1 and later releases, the log is now composed of an active log, limited to a maximum size of 128 GB, and an archive log that is limited in size only by the size of the file system where it resides.

The following table shows the recommended minimum sizes for the active log and archive log directories.

Storage pool deduplication enabled?
Active log directory
Minimum recommended size
Archive log directory
Minimum recommended size
16 GB
48 GB
32 GB
96 GB

To determine if larger active log and archive log sizes should be considered, review the following document:

For recommendations on the layout and placement of the active log and archive log files, review this document:

For the active and archive log directories, it is better to have them too large as opposed to too small. The values shown in the preceding table are recommended minimum values for production. Using these values or higher values can prevent log space problems for a server.

Back to top


The database for a V6.1 or V6.2 server is managed automatically by the server's database manager. The database is used to store and track information about server policies, stored data describing client files, and other attributes important to the server. It is also used as temporary storage space for intermediate results for queries or other processing that the server performs.

When the server database is initially configured (formatted), use multiple storage paths (multiple directories). As a general recommendation, start with 4 or more storage paths. The database manager for the Tivoli Storage Manager server has a better opportunity to exploit parallel I/O when using multiple storage paths.

To support database operations, the server's database manager manages and allocates many different system resources as it sees fit. Two primary resources that it uses are system memory and disk space for the database.

Important: The amount of database space that is needed can be influenced by the available memory on the system as well as the workloads that are being run. For example, the database manager orders the data in a specific sequence in response to the underlying SQL statement that was executed to request that data. If the database manager is unable to sort the result data using available memory, it "spills" into temporary database space by writing out portions of the sorted result to the database space allocated on disk.

Because of the relationship between result set size and available memory, the available space needed in the database can increase if these sort spills occur frequently. The database manager dynamically manages the memory used for these sort operations but ultimately a spill and use of temporary space in the server database might be unavoidable. The use of the temporary database space might then occur as a by-product of total workload on the server, or because the result for a single operation is so large that it cannot be contained and managed in memory.

One operation that can produce large result sets such that temporary database space is used is expiration. When expiration selects a given node and file space to process, it determines a candidate set of files to evaluate based on a SQL statement. If expiration is processing a node and file space that is very large, for example 10,000,000 objects, then it is unlikely that the database manager can contain that result in memory for the sort operation.

The primary considerations for database space related to the use of temporary space are:

Attention: 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.

Back to top

Database Operations
Full backups (TYPE=FULL) of the server database must be completed more frequently compared to V5. The primary reason is that pruning of the archive log space in the archive log directory occurs only as a result of a BACKUP DB TYPE=FULL operation. Full database backups are done automatically if the available active and archive log space gets low. However, to help prevent space problems, schedule regular TYPE=FULL database backups with some frequency.

If you are upgrading from V5 and have existing administrative schedules that manage the backup of the server database, evaluate these schedules:

Also evaluate how you manage volume history. The volume history occupies space in the server database, plus space for one or more files as configured by the VOLUMEHISTORY server option. Prune the volume history periodically by using the DELETE VOLHISTORY command, specifying deletion criteria based on how sequential media is used in your environment. In particular, consider the volumes used by database backups. With the increased frequency of TYPE=FULL database backups in V6, prune the volume history for volumes used by the database backup more frequently to manage the availability of scratch volumes for operations.

Attention: If the volume history file is not pruned periodically, server performance for operations that require sequential media can be adversely affected. For additional explanation of the importance of regular pruning of volume history, read the following documentation APAR:

Back to top

Upgrading from V5 to V6

If you are upgrading a server from an earlier version of Tivoli Storage Manager to V6.1 or V6.2, be sure to review the documented procedures and recommendations in the information center. Consider the following key items:

Note that it is possible and supported to upgrade from V5.x directly to V6.2.

Back to top

Deduplication effects on operations and resources

Tivoli Storage Manager V6.1 introduces deduplication for storage pools. To successfully use storage pool deduplication for V6.1 or V6.2, consider the following operational aspects:

  1. The duplicate identification (IDENTIFY) processes for the server make intensive use of the database and system resources. Because these processes place additional load on the CPU and memory of the system, schedule IDENTIFY processes to run when the additional load will not impact client operations or conflict with other server processes such as expiration.

    As a best practice, schedule the IDENTIFY process to run outside the client backup window and during a time period when it will not conflict with other server processes such as reclamation, migration, and storage pool backup.

    Consider using the Tivoli Storage Manager Administration Center. The Administration Center provides a wizard that guides you through configuring and scheduling an appropriate maintenance script that will run server processes in a recommended order.
  2. The effect of deduplication on system resources (CPU and memory) and the server active log is also related to the size of the file to be deduplicated. As the size of the file increases, more processing time, CPU, memory, and active log space are needed.

    Review the following document about server storage pool deduplication. In particular, consider the circumventions listed to avoid issues with this processing.

Back to top



Tivoli Storage Manager publishes a set of performance considerations and recommendations in the information centers. The tips and recommendations can help to successfully implement and deploy a Tivoli Storage Manager V6 server.

The following links provide additional guidance related to performance improvement:

Back to top

Renaming a Server

A Tivoli Storage Manager server is referenced in an environment by two attributes: the TCP/IP host name for the system where the server is running, and the server name that is defined by the SET SERVERNAME command. Changing either or both of these values has the following implications:

  1. If the TCP/IP host name is changed, it affects the Db2 database used by the V6 server. When the server is installed, attributes for its database are set that are dependent on the host name. If the host name is changed, the database must be updated to match this corresponding value. The following document discusses the procedure for changing the host name for the Db2 database that is used by a Tivoli Storage Manager server:

    For AIX:

    For Windows:

    For Linux:
  2. Changing the Tivoli Storage Manager server name using the SET SERVERNAME command affects clients and other operations. When you change the server name, the following warning is displayed:

    Changing the server name could adversely affect:  communication from the server to backup archive nodes, event logging, virtual
    volumes, library sharing, and storage agents used for LAN-free and
    server-to-server operations such as enterprise configuration.  See the administrator's guide for more information on these areas and the impact of changing the server name.

    For example, changing the server name affects Windows clients that are using generated passwords. See the Administrator's Guide (Setting the server name) or the information for APAR IC35878 for additional details.

Back to top

Operating system and hardware problems and workarounds

Back to top