IBM Support

Avoiding contention for server resources during client backup or archive.

Question & Answer


Question

I notice that there are times when my client backups run slowly and have difficulty finishing in the allotted window. If I monitor the server console during these times I can see that the server is busy as well. It seems that the server processes might be using resources that the client backup needs. What are the best practices to avoid contention for these resources during client backup?

Answer

During client backup, archive, or HSM migration sessions the Tivoli Storage Manager requires many resources to perform these actions. Resources include database logs, server locks, drives, mount points or volumes. For example, a client backup session might need a mount point, tape drive, and tape volume on which to store the data. After the session acquires these resources, another client session might start that needs to restore data that resides on the tape volume. The client restore session starts, must wait until the first session has unmounted the volume and released it, delaying the restore session.

The same resources might also be needed by server processes such as migration, reclamation, expiration, storage pool backup, and beginning with Tivoli Storage Manager V6.1, duplicate-identification processes. Anytime a server process starts and acquires resources needed to complete its task, those resources are unavailable to other server processes or client sessions. As a result, contention for resources that has a direct affect on performance and the ability to complete the operation in a timely manner.

Resource contention has a direct effect on performance and the ability to complete an operation in a timely manner. The problem of resource contention is more critical with long-running client sessions or server processes. Long-running sessions or processes handle data under the control of a transaction that prepares database entries for committing. New database entries are stored in the recovery log until they are committed to the database. Long-running sessions or processes can insert many of these entries under a single transaction pinning the recovery log. A pinned recovery log prevents all transactions from applying database changes and causes server processes to run slowly.

The following example shows how to schedule client sessions and server processes at different times to avoid resource contention and delays. The example omits some general setup steps to better focus on key task. The example uses a particular order for the server processes. However, you can reorder the processes to better fit your environment.

Important: When setting up schedules, try to prevent some server processes from launching automatically. For example, disable expiration, migration, reclamation, and duplicate-identification so that they can be scheduled later. Try using administrator-command schedules to run expiration daily.

Disabling expiration, migration, reclamation, and identify duplicates so they can be scheduled

When setting up schedules, it is better to prevent the automatic launching of some server processes. Expiration can be set up to run on a schedule using administrator command schedules and run daily. Perform the following steps in order to:



1. Disable automatic expiration with this command:

setopt expinterval 0

2. Disable automatic migration and reclamation processes by defining storage pools with commands like the following. Note that increasing the number of allowed processes for migration and reclamation might be needed in order for them to complete in a reasonable amount of time. The actual number of processes depends on available tape drives. If you already have storage pools defined, all of the parameters can be changed using the UPDATE STGPOOL command.

def devc LARGEFILE devt=file mountlimit=150 maxcap=20480m dir=/tsmfile
def stg FILEPOOL LARGEFILE maxscratch=200 reclaim=100 hi=100 lo=0 migpr=4 reclaimpr=4 next=tapepool

Setting reclaim=100 disables automatic reclamation while setting hi=100 disables automatic migration.

3. For Tivoli Storage Manager servers prior to V6.3.0, if you have storage pools defined with deduplication enabled, you will want to disable the Identify Duplicates processes. However, for Tivoli Storage Manager servers V6.3.0 and above, it is no longer necessary to prohibit Identify Duplicates processes from running concurrently with client ingest and this step can be skipped:


def stg FILEPOOL LARGEFILE maxscratch=200 reclaim=100 hi=100 lo=0  dedup=yes identifypr=0 migpr=4 reclaimpr=4


Setting up the client backup window

Next let's setup the client backup window. This example initiates an incremental backup of all associated nodes in the STANDARD domain. The window starts daily at 8:00PM and assumes server-prompted scheduling mode . Note that the long running schedules continue running past the duration, so a shorter duration may be need to force long running schedules to start close to the beginning of the start-up window.

def schedule standard nightly_backups description="Nightly backups of nodes in domain standard" starttime=20:00 duration=5 durunits=hours period=1 perunits=days


Setting up the server maintenance schedules

Now, schedule the server maintenance operations to run outside of the client backup window, with as little overlap as possible. The control of the timing of these schedules is made possible with the scheduled start time in combination with the duration specified with the command. Here's the schedule we are going to establish:

08:00 to end - storage pool backup
11:00 to 13:00 - identify duplicates processes
13:00 to 15:00 - expiration
14:00 to 16:00 - storage pool migration
16:00 to 18:00 - reclamation
18:00 to end - database backup (includes volume history and device configuration backup)
20:00 to end - client backup

1. Storage Pool Backup
/*--------------------------------------*/
/* Storage Pool Backup                  */
/*--------------------------------------*/
def script STGBACKUP "/* Run stg pool backups */"
upd script STGBACKUP "backup stg archivepool copypool maxproc=4 wait=yes" line=005
upd script STGBACKUP "backup stg backuppool copypool maxproc=4 wait=yes" line=010
upd script STGBACKUP "backup stg filepool copypool maxproc=4 wait=yes" line=020
upd script STGBACKUP "backup stg filepool2 copypool maxproc=4 wait=yes" line=025
upd script STGBACKUP "backup stg tapepool copypool maxproc=3 wait=yes" line=030
def sched STGBACKUP type=admin cmd="run STGBACKUP" active=yes desc="Run all stg pool backups." \
startdate=today starttime=08:00:00 dur=45 duru=minutes per=1 peru=day
commit


2. Identify Duplicates (Tivoli Storage Manager V6.1.0 and above)
/*--------------------------------------*/
/* Deduplication                        */
/*--------------------------------------*/

def script DEDUP "/* Run identify duplicate processes. */"
upd script DEDUP "identify duplicates FILEPOOL numpr=4 duration=120" \ line=010
upd script DEDUP "identify duplicates FILEPOOL2 numpr=2 duration=120" \
line=015
def sched  DEDUP type=admin cmd="run DEDUP" active=yes desc="Run identify duplicates." \
startdate=today starttime=11:00:00 dur=45 duru=minutes per=1 peru=day
commit

3. Expiration
/*--------------------------------------*/
/* Expiration
/*--------------------------------------*/
def script EXPIRE "/* Run expiration processes. */"
upd script EXPIRE "expire inventory wait=yes duration=120" line=010
def sched  EXPIRATION type=admin cmd="run expire" active=yes desc="Run expiration." \
  startdate=today starttime=13:00:00 dur=45 duru=minutes per=1 peru=day
commit

4. Migration
/*--------------------------------------*/
/* Storage Pool Migration               */
/*--------------------------------------*/

def script MIGRATE "/* Run stg pool migration */"
upd script MIGRATE "migrate stg archivepool duration=30 wait=yes" line=005
upd script MIGRATE "migrate stg backuppool duration=30 wait=yes" line=010
upd script MIGRATE "migrate stg filepool2 duration=60 wait=yes" line=015
def sched  MIGRATE type=admin cmd="run MIGRATE" active=yes desc="Migrate data to tape pools ." \
  startdate=today starttime=14:00 dur=45 duru=minutes per=1 peru=day
commit

5. Reclamation
/*--------------------------------------*/
/* Storage Pool Reclamation             */
/*--------------------------------------*/

def script RECLAIM "/* Run stg pool reclamation */"
upd script RECLAIM "reclaim stg filepool threshold=40 duration=120 wait=yes" line=005
upd script RECLAIM "reclaim stg filepool2 threshold=40 duration=120 wait=yes" line=008
upd script RECLAIM "reclaim stg tapepool threshold=60 duration=60 wait=yes" line=010
def sched  RECLAIM type=admin cmd="run RECLAIM" active=yes desc="Reclaim space from FILEPOOL and TAPEPOOL." \
  startdate=today starttime=16:00 dur=45 duru=minutes per=1 peru=day
commit

6. DB Backup
/*--------------------------------------*/
/* Database Backup                      */
/*--------------------------------------*/

def script DBBACKUP "/* Run DB backups */"
upd script DBBACKUP "backup db devc=ts3310devc type=full wait=yes" line=005
upd script DBBACKUP "backup volhist" line=010
upd script DBBACKUP "backup devconf" line=015
def sched  DBBACKUP type=admin cmd="run DBBACKUP" active=yes desc="Run database backup." \
  startdate=today starttime=18:00:00 dur=45 duru=minutes per=1 peru=day
commit

[{"Product":{"code":"SSGSG7","label":"Tivoli Storage Manager"},"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Component":"Server","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All Supported Versions","Edition":"Edition Independent","Line of Business":{"code":"LOB26","label":"Storage"}}]

Document Information

Modified date:
17 June 2018

UID

swg21419733