IBM Avoiding contention for server resources during clie...

http://www-01.ibm.com/support/docview.wss?uid=swg2...

Avoiding contention for server resources during client backup or archive.

Technote (FAQ) 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 mxcap=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 V6.1.0 and above, if you have storage pools defined with deduplication enabled, you will also want to disable the Identify Duplicates processes: def stg FILEPOOL LARGEFILE maxscratch=200 reclaim=100 hi=100 lo=0 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 dedup=yes identifypr=0 migpr=4

1 di 3

29/04/2013 22:53

IBM Avoiding contention for server resources during clie...

Setting up the server maintenance schedules

http://www-01.ibm.com/support/docview.wss?uid=swg2...

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

2 di 3

29/04/2013 22:53

IBM Avoiding contention for server resources during clie...

http://www-01.ibm.com/support/docview.wss?uid=swg2...

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

Copyright and trademark information

IBM, the IBM logo and ibm.com are trademarks of International Business Machines Corp., registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on the Web at "Copyright and trademark information" at www.ibm.com/legal /copytrade.shtml.

3 di 3

29/04/2013 22:53