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 AT VM.MARIST DOT EDU] On Behalf Of
Richard Sims
Sent: Monday, April 11, 2011 2:48 PM
To: ADSM-L AT VM.MARIST DOT 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
|
