Reclamation Best Practice?

[Outsyder]

Hi Guys.

We run a Reclamation once a week, on Sundays. For the past couple of weeks, it has been taking longer and longer. It now takes about 2 full days to complete. We set the reclaiming at 80% for our sequential storage pools.
What are the best practices that you guys run as far as Reclaiming? Looking for some inputs, hints as to how i could get this running better.

Thanks.

 

[ProbablyDown]

Well the higher the rec % the faster reclaim will go because the less data that has to be moved. I generally run it at about 90% because I can't have 2 drives occupied for too long. Once in a while I'll run it at 70% if I have a good length of "quiet time". The downside to high rec % is that more volumes are in use. Typically people try to run it at 60%. This will use the least resources and should speed up restores b/c you don't have to mount so many volumes.

Try to run it after expiration. If 80% takes too long try 90%.

I run this query in a tsm script I call queryreclaim:
select volume_name,stgpool_name,pct_reclaim from volumes where pct_reclaim>$1 and status='FULL' order by stgpool_name

to execute I say "run queryreclaim 90" to see all the 90% empty tapes - that gives me an idea of how long it will take. you can enter any value you want tho - 80, 70 etc...

Give it a try, maybe that will help...

 

[Outsyder]

Thank you for the response. I will give the query a try.
So if i understand this correctly, if i were to find a nice, long 'quiet' time period, i could try running a reclaim at 60%, which would free up some tapes and allow me to recuperate some Scratch tapes?
It seems like we are eating up scratch tapes so quickly...Maybe i should check my retention as well. (i just took over TSM from an admin that left the company, so i am trying to learn/see the setup quickly!)

Thanks again.

 

[ProbablyDown]

Absolutely.... and you can cancel reclamation at anytime without causing any problems.

Things that eat scratches:
1) not running reclamation
2) using colocation - this attempts to keep all node data on fewer tapes, ergo, using more tapes over all. But restores are much faster
3)backupsets - this will put all active node files on a single tape (or multiple if there is enough data) - so a 3GB server backup will still use an entire tape.

There are probably others - dbbackups, drm etc... but generally you can get scratches back by regularly running and completing rec...

 

[LED888]

A few days ago found this tech doc.

http://www-1.ibm.com/support/docview.wss?uid=swg21194585

Tech Doc: 1194585

Reclamation Tips and Hints
Technote (FAQ)

Problem
The purpose of this document is to relate some additional tips and hints that may help IBM Tivoli Storage Manager administrators avoid a call to the Tivoli Support line as well as to provide some interesting points for discussion.

Cause
Managing reclamation so as to not cause performance or failure issues

Solution
Originally published as field guide 7003828 no longer available
When the percentage of reclaimable space on a volume exceeds the reclamation threshold set for the storage pool, the volume is eligible for reclamation. The server checks whether reclamation is needed at least once per hour and begins space reclamation for eligible volumes. You can set a reclamation threshold for each sequential access storage pool when you define or update the pool.

During space reclamation, the server copies files that remain on eligible volumes to other volumes. During reclamation, the server copies the files to volumes in the same storage pool unless you have specified a reclamation storage pool. Use a reclamation storage pool to allow automatic reclamation for a storage pool with only one drive.

The server also reclaims space within an aggregate file. An aggregate is a physical file that contains multiple logical files that are backed up or archived from a client in a single transaction. Space within the file becomes reclaimable space as logical files in the aggregate expire or are deleted by the client. The server removes unused space from expired or deleted logical files as the server copies the aggregate file to another volume during reclamation processing. However, reclamation does not aggregate files that were originally stored in non-aggregated form. Reclamation also does not combine aggregates to make new aggregates. You can also reclaim space in an aggregate by issuing the MOVE DATA command.

After the server moves all readable files to other volumes, one of the following occurs for the reclaimed volume:
If you have explicitly defined the volume to the storage pool, the volume becomes available for reuse by that storage pool.
If the server acquired the volume as a scratch volume, the server deletes the volume from the TSM database.

Volumes that have a device type of SERVER are reclaimed in the same way as other sequential access volumes. However, because the volumes are actually data stored in the storage of another TSM server, the reclamation process can consume network resources.

Volumes in a copy storage pool are reclaimed in the same manner as a primary storage pool except for the following:
Offsite volumes are handled differently.
The server copies active files from the candidate volume only to other volumes in the same storage pool.

General Information
Each file stored in a TSM storage pool has an expiration date. Because of this, the TSM server must monitor all sequential (tape) volumes to reclaim volumes as needed. A volume needs to be reclaimed when the empty space on the volume exceeds the reclamation threshold. Empty space on a tape volume is comprised of space never used or space created as files expire.

Reclamation of sequential storage pool volumes is an automatic function of the TSM server. At least once every hour, the server checks to see if reclamation is needed. The only manual intervention to this process is the value of the reclamation threshold. A lower threshold setting will cause reclamation to run sooner and more frequently.

If reclamation does not run to completion daily, the number of used tape volumes will most likely increase, and the number of scratch volumes will decrease.

Filling tape volumes with files that have the same expiration date will result in the elimination of data transfer during reclamation. Once the files on the volume have expired, the volume will be automatically returned to the scratch pool. Attention to this scenario can significantly reduce load on the TSM server for reclamation.

TIP: Reclaiming Volumes in a Storage Pool with One Drive
The following instructions give the procedure required to reclaim volumes in a storage pool where one drive is involved:
Create a primary stgpool of devclass FILE with a name that clearly states its purpose, i.e. Reclaim_pool. This stgpool must be of sufficient size to process the entire amount of reclaimable data in a 24 hour period. This pool will be automatically expandable and contractible as needed.
Set the Nextstgpool parameter in the Reclaim_pool to point to the original tape pool. Using this technique will maximize efficiency of tape volumes.
Set the Reclaim parameter in the Reclaim_pool to 100%. Migration will manage this volume’s space.

HINT: Sharing Tape Libraries Between Multiple TSM Servers
Establish TSM Library Sharing when accessing a single tape library with multiple TSM servers. This will eliminate drive contention during reclamation process. 2

HINT: Reclamation Volumes Stuck in Drive After Reclamation Process
Try each of the following steps, in order, until volume is successfully removed and stowed by the library robotics.
Recycle (power-off, power-on) tape library.
Recycle TSM server. (Update stgpool reclaim value to 100% before halting server. Reset the reclaim value to the original value after the volume has been removed and the TSM server is back in service.)
Query the volume and inspect its status. If there is a discrepancy between this status and the volume’s physical state, issue the Audit Library command to resolve the discrepancy.

TIP: Sizing TSM Reclamation Stgpools
Grouping data that has like retention periods minimizes reclamation processing. This is most effective where clients have many, large files (as with database backups). As an illustration, consider the following. All files within a given tape volume have the same retention period and were written to that volume on the same day. In this case, reclamation would be eliminated because all files would expire at the same time and the volume would simply be returned to the scratch pool.
Exact sizing of a reclamation stgpool is difficult. Retention values, migration limits, reclamation limits, number of files, size of files and frequency of backups are the primary factors. Observing trends based on historical data, tracking reclamation amounts and time periods, is the best gauge of a reclamation stgpool’s proper size.

HINT: Reclamation Volumes that are Not Returned to Scratch
Check storagepool definition for the REUSEDELAY option. This is the number of days after a volume becomes empty that it will be in a PENDING state before returning to SCRATCH
Customers using a reclamation storage pool with a dev type of file may experience a situation where their reclaimed volumes are not returned to scratch status. This problem was identified and fixed in the TSM server 4.2.2.0 code.


Good Luck,
Sais

 

[mbourne2006]

Hopefully not too inflammatory, but here goes

"After the server moves all readable files to other volumes, one of the following occurs for the reclaimed volume:
If you have explicitly defined the volume to the storage pool, the volume becomes available for reuse by that storage pool.
If the server acquired the volume as a scratch volume, the server deletes the volume from the TSM database."

This is incorrect. Irrespective of whether or not the volume was explicitly assigned, once a volume has been reclaimed it enters into the "PENDING" state. It will not be elligible for re-use (or deletion) until the number of days specified in the "REUSEDELAY" parameter of the parent storage pool have passed.

HTH

Kind Regards,
Matthew Bourne
"Find a job you love and never do a day's work in your life.