ADSM-L

Re: [ADSM-L] : TSM Running out of Scratch Tapes

2013-07-09 10:41:51
Subject: Re: [ADSM-L] : TSM Running out of Scratch Tapes
From: Skylar Thompson <skylar2 AT U.WASHINGTON DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 9 Jul 2013 07:39:33 -0700
Do you use library sharing? If you do, make sure the encryption settings
on the device classes are the same on all the library clients. The label
itself will be encrypted if the device class allows, and a library
client with encryption disabled will not try to re-label the volume if
it sees an encrypted label.

-- Skylar Thompson (skylar2 AT u.washington DOT edu)
-- Genome Sciences Department, System Administrator
-- Foege Building S046, (206)-685-7354
-- University of Washington School of Medicine

On 07/08/13 22:31, Adeel Mehmood wrote:
> Dears ,
>
> We are receiving below errors and the Scratch tapes goes to ZERO
>
> 07/04/2013 22:58:44      ANR8355E I/O error reading label for volume 001736 in
>                           drive DRIVE15 (mt10.0.0.2). (SESSION: 32773)
> 07/04/2013 23:04:23      ANR8355E I/O error reading label for volume 000588 in
>                           drive DRIVE4 (mt7.0.0.1). (SESSION: 32799)
> 07/04/2013 23:04:35      ANR8355E I/O error reading label for volume 000482 in
>                           drive DRIVE15 (mt10.0.0.2). (SESSION: 32806)
> 07/04/2013 23:10:55      ANR8355E I/O error reading label for volume 001058 in
>                           drive DRIVE4 (mt7.0.0.1). (SESSION: 34240)
> 07/04/2013 23:11:01      ANR8355E I/O error reading label for volume 002081 in
>                           drive DRIVE15 (mt10.0.0.2). (SESSION: 34242)
> 07/04/2013 23:15:49      ANR8355E I/O error reading label for volume 000468 in
>                           drive DRIVE15 (mt10.0.0.2). (SESSION: 34242)
> 07/04/2013 23:16:21      ANR8355E I/O error reading label for volume 000828 in
>                           drive DRIVE4 (mt7.0.0.1). (SESSION: 34240)
> 07/04/2013 23:20:33      ANR8355E I/O error reading label for volume 002284 in
>                           drive DRIVE15 (mt10.0.0.2). (SESSION: 34242)
> 07/04/2013 23:21:13      ANR8355E I/O error reading label for volume 002084 in
>                           drive DRIVE4 (mt7.0.0.1). (SESSION: 34240)
> 07/04/2013 23:26:29      ANR8355E I/O error reading label for volume 001367 in
>                           drive DRIVE15 (mt10.0.0.2). (SESSION: 34255)
> 07/04/2013 23:28:24      ANR8355E I/O error reading label for volume 000386 in
>                           drive DRIVE4 (mt7.0.0.1). (SESSION: 34215)
> 07/04/2013 23:36:08      ANR8355E I/O error reading label for volume 001804 in
>                           drive DRIVE15 (mt10.0.0.2). (SESSION: 34215)
> 07/04/2013 23:37:04      ANR8355E I/O error reading label for volume 002323 in
>                           drive DRIVE4 (mt7.0.0.1). (SESSION: 34255)
> 07/04/2013 23:44:47      ANR8355E I/O error reading label for volume 001814 in
>                           drive DRIVE15 (mt10.0.0.2). (SESSION: 34255)
> 07/04/2013 23:45:05      ANR8355E I/O error reading label for volume 002535 in
>                           drive DRIVE4 (mt7.0.0.1). (SESSION: 24769)
>
> Thanks & best regards,
> Adeel Mehmood
>
> From: Adeel Mehmood
> Sent: Tuesday, July 9, 2013 7:36 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: RE: [ADSM-L] : TSM Running out of Scratch Tapes
>
>
> Dear ,
>
>
>
> Thanks for your response . please find the answers below .
>
>
>
> It is most useful if you state which version of TSM server you are running.   
> -------------- > TSM 6.2
>
> The OS it runs on and the tape media (LTO3/4/5 etc.) would be helpful 
> -------------------- > Windows 2008 Server , configured with SL3000 Library 
> through ACSLS Software having 14 x HP LTO4  FC Tape Drives.
>
>
>
> What retention policies are in place for the domain copy groups? If NOLIMIT 
> is in force, then data will never expire and will eventually use all of your 
> tapes
> ---- > Retention Polices seems to be working fine as they are In place for 
> more than two years  & half years and we started facing this problem couple 
> of weeks back .
>
>
> When you say tapes are becoming 'unavailable', is this the status of the 
> volume within TSM? (Do a 'q vol f=d' to check). If so, this is often because 
> you are trying to use tapes that have been physically removed from the 
> library. If TSM wants to use that tape, it will eventually place the tape in 
> an 'UNAVAILABLE' state because it cannot mount the volume in the library as a 
> result of being removed.
>
> ----- > we are 100 % sure that the tapes are physically inside .The NEW/OLD 
> tapes become UNAVAILABLE , whenever the TSM try to use them for backup or 
> restore.
> but once we make them available , we could use them for some time . till they 
> get unavailable again .
>
>
>
> In terms of running low on scratch, as the previous poster said, make sure 
> expiration and reclaim is running. In particular, make sure reclaim is 
> running and actually completing. The SUMMARY table will report on expiration 
> and reclaim activity over a period of time (usually 28 days)
>
> ----- > we double check the same.
>
>
>
> How many versions of database backups do you retain?
>
> ------ > 14 versions
>
>
>
> These are common causes of tape problems.
>
> ------ > we are using Brand New Tapes and they are also getting UNAVAILABLE ,
> also we opened a case with Library Vendor and they said all is well .
>
>
>
> Best regards, Adeel
>
>
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf 
> Of white jeff
> Sent: Tuesday, July 9, 2013 12:17 AM
> To: ADSM-L AT VM.MARIST DOT EDU<mailto:ADSM-L AT VM.MARIST DOT EDU>
> Subject: Re: [ADSM-L] : TSM Running out of Scratch Tapes
>
>
>
> Hi
>
>
>
> It is most useful if you state which version of TSM server you are running.
>
> The OS it runs on and the tape media (LTO3/4/5 etc) would be helpful
>
>
>
> What retention policies are in place for the domain copygroups? If NOLIMIT is 
> in force, then data will never expire and will eventually use all of your 
> tapes
>
>
>
> When you say tapes are becoming 'unavailable', is this the status of the 
> volume within TSM? (Do a 'q vol f=d' to check). If so, this is often because 
> you are trying to use tapes that have been physically removed from the 
> library. If TSM wants to use that tape, it will eventually place the tape in 
> an 'UNAVAILABLE' state because it cannot mount the volume in the library as a 
> result of being removed.
>
>
>
> In terms of running low on scratch, as the previous poster said, make sure 
> expiration and reclaim is running. In particular, make sure reclaim is 
> running and actually completing. The SUMMARY table will report on expiration 
> and reclaim activity over a period of time (usually 28 days)
>
>
>
> Establish the percent-reclaimable space of your tape volumes. Use this
>
> command:
>
>
>
> SELECT VOLUME_NAME, STGPOOL_NAME, PCT_RECLAIM, STATUS FROM VOLUMES WHERE
>
> VOLUME_NAME LIKE '%L3'   (This is assuming you are using LTO3 tape. Change
>
> accordingly)
>
>
>
> How many versions of database backups do you retain?
>
>
>
> These are common causes of tape problems.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On 8 July 2013 10:13, Adeel Mehmood <Ad.Mehmood AT diyarme DOT 
> com<mailto:Ad.Mehmood AT diyarme DOT com>> wrote:
>
>
>
>> Dears ,
>
>>
>
>> We are facing problem as the TSM scratch tapes are running out , also
>
>> the tapes becoming unavailable .
>
>> Please advise , how to handle this issue .
>
>>
>
>> Thanks , Adeel
>
>>
>
>> ________________________________
>
>>
>
>> D I S C L A I M E R
>
>>
>
>> The information in this email and in any files transmitted with it, is
>
>> intended only for the addressee and may contain confidential and/or
>
>> privileged material. Access to this email by anyone else is unauthorized.
>
>> If you receive this in error, please contact the sender immediately
>
>> and delete the material from any computer. If you are not the intended
>
>> recipient, any disclosure, copying, distribution or any action taken
>
>> or omitted to be taken in reliance on it, is strictly prohibited.
>
>> Statement and opinions expressed in this e-mail are those of the
>
>> sender, and do not necessarily reflect those of the company.
>
>>