Joni,
Check the actlog @ the time of the failure, to determine the cause of the
failure..
I run a script to find unaccessible volumes, before I start reclamation..
Here is the script if you want to define it in your env..
"select volume_name, access, stgpool_name,devclass_name from volumes where
devclass_name like '%3590%' and volume_name in (select volume_name from
libvolumes) and access not like 'READWRITE' order by access, stgpool_name"
Of course you will have to change the devclass name from 3590 to whatever
yours is..
I'm thinking that maybe the onsite copy is unaccessible, so it cannot copy
offsite data to the new tape..
Gabriel C. Wiley
ADSM/TSM Administrator
AIX Support
Phone 1-614-308-6709
Pager 1-877-489-2867
Fax 1-614-308-6637
Cell 1-740-972-6441
Siempre Hay Esperanza
Joni Moyer
<joni.moyer@HIGHM To: [EMAIL PROTECTED]
ARK.COM> cc:
Sent by: "ADSM: Subject: Re: Reclamation for copy pools
Dist Stor
Manager"
<[EMAIL PROTECTED]
.EDU>
03/25/2002 08:36
AM
Please respond to
"ADSM: Dist Stor
Manager"
Is it normal to receive the following failure message for reclamation for a
copy pool volume that is not in the silo?
03/25/2002 00:59:09 ANR0984I Process 8 for SPACE RECLAMATION started in
the
BACKGROUND at 00:59:09.
03/25/2002 00:59:09 ANR1040I Space reclamation started for volume 491674,
storage pool TAPECOPYSPMGNT (process number 8).
03/25/2002 00:59:09 ANR1040I Space reclamation started for volume 483401,
storage pool TAPECOPYSPMGNT (process number 8).
03/25/2002 00:59:09 ANR0985I Process 8 for SPACE RECLAMATION running in
the
BACKGROUND completed with completion state FAILURE
at
00:59:09.
Thanks!!!!
Joni Moyer
Associate Systems Programmer
[EMAIL PROTECTED]
(717)975-8338
"Wayne T.
Smith" To: [EMAIL PROTECTED]
<[EMAIL PROTECTED] cc:
U> Subject: Re: Reclamation for
copy pools
Sent by:
"ADSM: Dist
Stor Manager"
<[EMAIL PROTECTED]
IST.EDU>
03/22/2002
04:04 PM
Please respond
to "ADSM: Dist
Stor Manager"
On 22 Mar 2002 at 13:37, Joni Moyer wrote, in part:
> Reclamation is set for 60 on both the onsite tape pool and the copy
> pools(offsite).
If you have enough tape drives so that reclamations don't interfere
with other need for drives, then this is fine. I don't, so my tape
pools are set at reclaim=100 for most of the time, and at reclaim=nn
for the times I don't mind reclamations starting.
In general reclamations are independent of your protecting your server
and client data, except that (1) you need to have enough non-full tapes
to write new data, and (2) restores are generally faster from
relatively full tapes because the generally require fewer tape mounts.
> ... and then in turn the reclamation for that volume fails because it
> cannot be mounted in the silo. I didn't think it was possible to run
> reclamations for the tapes that are in the vault. How do I prevent
> reclamation from trying to reclaim these volumes when they are also
> technically recognized in the copy pool?
I'm not sure why you get the failure. You surely can reclaim files from
offsite tapes ... *SM simply mounts primary volumes (onsite tapes) in
its building of a new copypool tape. I've not tried to reclaim a
copypool volume that was onsite; does *SM then use the copypool volume
directly? If so, it might have been confused by the sequence (1)
determine reclaim of a tape is to proceed, (2) your mark tape as
offsite, and (3) try to mount tape, only to find tape is set with
access=offsite. Pure speculation.
> I also have many volumes in the offsite copy pool that are in the status
> of pending and they are in the offsite vault. Does TSM interact with
> TMS to bring those volumes back to the copy pool in the silo or do I
> have to run a job to do this?
The pending status exists in case you have a disaster and need to
restore an old copy of your DB. You want the tapes, as set in that old
DB copy, to continue to hold the expected data and not be overwritten.
So you set your reuse delay to what makes sense for your DB backups. If
you might someday want to restore a DB backup that is 7 days old, your
reuse delay must be at least 7. (The alternative is that you can't
trust what's on any tape and so must mount and audit all of them.
Yeck).
I don't have or know TMS, but here is some of what goes on:
Your (normally status=full or filling) tapes are set as access=offsite
when you take your tapes to "the vault" (DRM, if you have it, has a
couple of intermediate steps). Eventually, because of inventory
expirations (and reclamation), the tapes become status=pending. Once
your reuse delay completes, the tapes become status=empty ... still
with access=offsite. Now you have some logically empty tapes in your
vault.
At some point you decide to retrieve these for reuse (again, if you
have DRM, there are a few states the tapes can go through). Once you
have returned the tapes, (remember they're already status=empty), you
update their *SM state to access=readwrite (assuming you're using a
private pool and not scratching tapes you're done with). (Sorry for the
bad grammar!)
If you need it, there is a "location" field that you can use with the
update volume/volhist commands to help keep track of where the tapes
are really located (if you don't use DRM). With DRM see the Q DRMEDIA
and MOVE DRMEDIA commands.
Hope this helps, wayne
Wayne T. Smith [EMAIL PROTECTED]
ADSM Technical Coordinator - UNET University of Maine System
