I have heard it often of TSM administrators wondering why the TSM reclamation process is slow & clumsy process. The good part most of these administrators is that they understand the importance of reclamation & how it help their backup become more efficient & save on tapes, though they still wonder why it takes too longs. I had decided to give my point of view on this.
1- One of the main reasons for the reclamation process to be slow is that you don’t have enough tape drives. If you have only one tape drive into your library then you can have a seriously slow & none efficient reclamation process, as each time you need to reclaim a tape, TSM will have to copy the full tape to the disk, then reclaim the volume on the disk to another tap. So you are basically repeating the reclamation process twice.
2- You have a slower tape drives. Actually the speed of your reclamation is totally dependent on the mechanical speed of your tape drive. To make it clearer imagine a tape with only 7% valid data. When the reclamation process run for this tape, your tape drive will waste most of the time forwarding the tape to the point where is your data is written. The more scattered the data the more forwarding the tape have to do to get to the data. So the slower the drive, the slower it will take to totally forward the full tape looking for your data.
3- Another factor for slow reclamation process, which is specifically for offsite tape. If offsitereclaimlimit=X paramater has not been setup correctly. As the offisite reclamation by default try to reclaim all the tapes which meet your reclamation threshold at the same time. So imagine if you have a 60 tapes which meet your threshold at the same time, it means your reclamation process will take for ever & will never finish unless you have endless drives. To avoid this problem always try to set the parameter offsitereclaimlimit=X, where the best value of X would be the number of drives you have in your tape library. This parameter will limit the amount of offline tapes that TSM will try to reclaim at a certain time.
So where people tend to blame TSM for the slow reclamation process, it seems to be most of the time due to insufficient hardware configuration or TSM misconfiguration instead of the software code it self.
I hope that help some one get the idea of reclamation better, and before complaining about the TSM reclamation process you check your hardware & TSM configuation.
Enjoy,
TSM Guru
Subscribe RSS 2.0 feed. Leave a response, or Trackback from your own site.
Best Deal Ads :
3 Responses to 'Why is TSM reclamation a slow and clumsy process?'
Leave a Reply
- Blades (2)
- IBM Blades (2)
- EMC (1)
- VPLEX (1)
- How to (1)
- Management Software (4)
- Problem resolutions (0)
- Storage (18)
- Tips & Tricks (7)
- Tivoli (22)
- FlashCopy Manager (19)
- TSM (3)
- TSM 6.1.x.x (2)
- Tutorials (11)
- VMware (4)
- admin: As long both of them reside on the DS8000 it should be possible to acheive
- HAMAYUN ALI SHAH: HELLO I want to copy/backup DS8000′s volumes on a Windows Server 2003 machine, and not from...
- Kamesh: Really Useful!!!
- Shaamil Thorne: Hi There, Do you perhaps know how to do this on a DS4000/5000 storage subsystem. Using a Windows...
- joe: a 30 Days testversion can be downloaded from the IBM FTP Server. Note that the files will only be released there...
- IBM Tivoli Storage Manager Guru Blog: TSM
- How to Videos: Install IBM Systems Director 6 Common Agent on AIX | How to Install IBM Systems Director 6 Common...
- 8.3. Microsoft vShadow Transaction Consistent Database Cloning to a different server: Back to: IBM Tivoli Storage...
- 8.2. IBM TFCM Transaction Consistent Database Cloning to the same server: Back to: IBM Tivoli Storage FlashCopy...
- 8.1. IBM DS8000 Boot from SAN Operating System Cloning: Back to: IBM Tivoli Storage FlashCopy Manager Tutorial Index
- VMware ThinAPP Antivirus Best Practices
- IT Solutions LIVE WEBINARs Page
- New StarWind iSCSI SAN v5.8 and Hyper Backup Plug-in are a New Level of Data Protection
- IBM XIV, IBM SVC, IBM Storwize V7000 support VAAI is here & DS8000 is on the way
- The first VMware vSphere Metro Storage Cluster (vMSC) Supported with EMC VPLEX
- HP Storage P4000 Virtual Storage Appliance installation on vSphere 5
- Why Use IBM Tivoli Storage Manager?
- Format Completed with Return Code 499
- How do you remove a server instance without uninstalling the TSM server?
- IBM 000-206 High-End Disk Solutions for Open Systems Version 1






Another issue is that those tapes which have less reclaimable space take longer to reclaim. If I’ve run into any issues that have caused my reclamation process to fail and I need to reclaim a lot of tapes, I’ll do the following steps. First, run a query for how many tapes there are above the 50% threshold and then on higher numbers (I usually start at 95%). If there is a good number of reclaimable tapes above 95, then I’ll just run the reclamation on those tapes which will get done pretty quickly.. then I’ll move on to lower numbers thus forcing the quicker reclamation processes to finish first. Here are the queries and commands I use:
select count(*) as EMPTY_VOLUMES from volumes where STATUS=’EMPTY’
SELECT count(*) FROM Volumes WHERE PCT_RECLAIM>50
SELECT count(*) FROM Volumes WHERE PCT_RECLAIM>95
reclaim stgpool 3584STGPOOL threshold=95 dur=840
I have greatly increased the efficiency of reclamation by scripting it so the easy/fast to reclaim tapes get done first.
The easiest reclamation is the one you don’t do. Keep sufficicent free slots and tapes so that data expires naturally. Also separate database backups that will expire in strict time sequence into their own pools that do not run reclamation.