In Tivoli Storage Manager you can improve the performance of restore operations by choosing appropriate server settings. First let us understand how restore works. Basically, there are two types of restore processes. The client uses two different methods for restore operations: Standard restore (also called classic restore), and no-query restore.
Standard Restore or Classic Restore
Standard restore requires more interaction between the client and the server, and multiple processes cannot be used for the restore. This is a traditional type of restore where client communicates with TSM server for every individual file which is to be restored. As a result there will be number of communication requests flowing to and fro from client and server.
No-Query Restore
The no-query restore requires less interaction between the client and the server, and the client can use multiple sessions for the restore process. The no-query restore process is useful when restoring large file systems on a client with limited memory because it avoids some processing that can affect the performance of other client applications. In addition, it can achieve a high degree of parallelism by restoring with multiple sessions from the server and storage agent simultaneously.
Also Read: TSM Server Performance Tuning Parameters
The method is called no-query restore because the client sends a single restore request to the server instead of querying the server for each object to be restored. The server returns the files and directories to the client without further action by the client. The client accepts the data coming from the server and restores it to the destination named on the restore command. The no-query restore process is used by the client only when the restore request meets both of the following criteria
1) When we enter the restore command with a source file specification that has an unrestricted wildcard
An example of a source file specification with an unrestricted wildcard is
/home/mydocs/2015/*
An example of a source file specification with a restricted wildcard is
/home/mydocs/2015/sales.*
2) When we do not specify any of the following client options with restore command- inactive, latest, pick, fromdate, todate
If you want to use the classic restore then use ?* in the source file specification rather than *. For example:
/home/mydocs/2002/?*
Increasing performance by controlling TSM Restore Sessions
To use multiple sessions, data for the client must be on multiple, sequential access volumes or a combination of sequential access volumes and disk. The data for a client usually becomes spread out over some number of volumes over time. This occurs deliberately when collocation is not used for the storage pool where the client data is stored. To potentially benefit from multi-session restores, consider collocating client data by group. Collocation by group can cause data for a node to be distributed on more than one volume while keeping the group's total data on as few volumes as possible.
Also Read: SQL commands to query TSM Server
The Tivoli Storage Manager server can set the maximum number of mount points a node can use on the server using the MAXNUMMP parameter. If the resourceutilization option value exceeds the value of the MAXNUMMP on the server for a node, the backup can fail with an Unknown System Error message.
For example, if the data you want to restore is on 5 different tape volumes, the maximum number of mount points is 5 for your node, and resourceutilization is set to 3, then 3 sessions are used for the restore. If you increase the resourceutilization setting to 5, then 5 sessions are used for the restore. There is a 1 to 1 relationship to the number of restore sessions allowed for the resourceutilization setting. Multiple restore sessions are only allowed for no query restore operations.
Also Read: SQL commands to query TSM Server
The Tivoli Storage Manager server can set the maximum number of mount points a node can use on the server using the MAXNUMMP parameter. If the resourceutilization option value exceeds the value of the MAXNUMMP on the server for a node, the backup can fail with an Unknown System Error message.
For example, if the data you want to restore is on 5 different tape volumes, the maximum number of mount points is 5 for your node, and resourceutilization is set to 3, then 3 sessions are used for the restore. If you increase the resourceutilization setting to 5, then 5 sessions are used for the restore. There is a 1 to 1 relationship to the number of restore sessions allowed for the resourceutilization setting. Multiple restore sessions are only allowed for no query restore operations.
Restore operations themselves are not restricted on mount points. The MAXNUMMP parameter in the REGISTER NODE or UPDATE NODE command applies to restore in that the client can restrict the number of sessions based on the combination of the MAXNUMMP value and the client's RESOURCEUTILIZATION value. Set the client option for resourceutilization to one greater than the number of desired sessions. The client option can be included in a client option set. Issue the restore command so that it results in a no query restore process.
Controlling resourceutilization by a client
- For backup operations, you might want to prevent multiple sessions if the client is backing up directly to tape, so that data is not spread among multiple volumes. Multiple sessions can be prevented at the client by using a value of 2 for the resourceutilization option on the client.
- For restore operations, set the resourceutilization option to one greater than the number of desired sessions. Use the number of drives that you want that single client to use.
Another method which can aid in both the backup and restore of client nodes with critical data is to manage the backup process through multiple commands instead of multiple sessions. For example, when using multi-session backup, multiple backup sessions may be contending for the same underlying hard disk, thus causing delays.
Also Read: Starting TSM server in maintenance mode
Also Read: Starting TSM server in maintenance mode
An alternative is to manage this process externally by starting multiple dsmc commands. Each command backs up a pre-determined number of file systems. Using this method in conjunction with collocation at the file space level can improve backup throughput and allow for parallel restore processes across the same hard drives.
You must issue multiple commands when you are restoring more than one filespace. For example, when you are restoring a c: drive and a d: drive on a Windows system you must issue multiple commands.
Consider using multiple commands when you are restoring a single, large file space, and all of the following conditions are true
- The data was backed up to a storage pool that had collocation set to FILESPACE. Files will be on multiple volumes, and the volumes can be mounted by multiple processes.
- The files are approximately evenly distributed across the different top-level directories in the file space.
- The number of top-level directories in the file space is not large.
- You can issue commands for the different top-level directories, and the commands do not overlap (so that the same file is not restored multiple times by different commands).
Issue multiple commands either by issuing the commands one after another in a single session or window, or by issuing commands at the same time from different command windows. When you enter multiple commands to restore files from a single file space, you must specify a unique part of the file space in each restore command. Be sure that you do not use any overlapping file specifications in the commands. To display a list of the directories in a file space, use the query backup command on the client. For example:
dsmc query backup -dirsonly -subdir=no /usr/
Can I crease the Maxnump and resourceutil while backup is running?
ReplyDeleteWill that make backup run more sessions?