On occasion I have deleted a vol from a copypool when the percent utilized number dropped to a couple of percent. In our setup we have three identical data pools so we should ok but it's not something I do very often.
I have watched the offsite reclamation process sit there for most of an hour or more just thinking about it before it would load a tape and get to work. I'm kinda ok with that because of all the work going on under the hood. David Tyree Interface Analyst South Georgia Medical Center 229.333.1155 Confidential Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. -----Original Message----- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Richard Sims Sent: Monday, April 11, 2011 2:48 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] reclamation question A more draconian method (not recommended) is to perform a Delete Volume for the copy storage pool volumes you would reclaim, where their former content would be freshly written to tape in the next Backup Stgpool. That leaves you with one less copy of the data, of course, so not the best approach. The reclamation of offsite copy pool tapes can put a drag on your TSM server, as the processing involves inventorying the files on the offsite tape to be reclaimed, then identifying the onsite tapes containing the files, and compile that into a list ordered so as to minimize mounts and repositioning. That can be a lot of database work, which can be observable as reclamation processing seems to pause for a time. Where realistic, I like to bring a batch of offsite tapes back onsite, check them all in at once, then start reclaiming, where the span-from and span-to companion volumes are thus likely to be mountable, preventing the process from having to revert to primary pool tapes for the duration of the volume reclaim because of the spanning. (It continues using the surrogate primary pool volume(s) even after having gotten past a span into the volume being reclaimed, where such processing can result in a bunch of primary pool tape mounts and think time between each, resulting in a reclaim which can run about 8x slower than a straight reclaim.) You can spot check for spanning by performing Query Content <Volser> F=D Count=1 for a span-into condition, and Query Content <Volser> F=D Count=-1 for span-out-of. To assess process progress, I employ a macro called 'processes', whose contents are: SELECT Char(PROCESS_NUM,6) as "Number", PROCESS as " Process ", - Left(Char(START_TIME),19) as " Start Time ", - FILES_PROCESSED as " Files ", Char(BYTES_PROCESSED,14) as " Bytes ", - STATUS as " Status " FROM PROCESSES This is more useful than Query PRocess in that you can directly see how much data has been checkpoint committed, not just how much has been physically operated upon thus far. Richard Sims http://people.bu.edu/rbs/ADSM.QuickFacts