TSM scratch tapes issue need help

[sai]

Hello Guys,

I have a different problem here. In our TSM environment i have like 3000 tapes. TSM picked up first 0-1600 and wrote data to them, then it left 1601-1955 as scratch and starting writing data on 1956 and so on.

when i do a q libvol they show up and i'm not sure why we have this issue.

we also have another issue with DB volumes that are back to scratch where the reuse delay option is set to 0 days

I have like 50 tapes that became scratches and are not being used they were DB tapes. Need help on this.

Thanks,

Sai

 

[RaCol]

Hi sai,

TSM has no special order how to select scratch tapes for writing and assigning them to a Storage Pool. So I guess that you have be patient that TSM starts selecting tapes in the 1601 - 1955 range for writing. Normally the scratch tapes, which were before DB tapes should be selected also sonner or later. If you are not sure you could enforce selecting a tape during DB backup with the following command: backup db type=... devcl=... volume=... --> have a look to the help for this command with "help backup db" in the command line.

Regards, Ralf

 

[sai]

Ralf,

Thanks for quick response i did read in few posts that TSM would pick tapes in ascending order so was little bit tensed.

coming to REUSEDELAY i believe it is set to every stg, in few of the forums too i saw when you set REUSEDELAY= 0 DAYS it should use the tape immediately so want to make sure that there is nothing wrong with our system

 

[DazRaz]

For the database backups, look at Set DRMDBB. To retain database backups for 5 days use 'Set DRMDBB 5'. Typically, you should then set the reuse delay on the storage pools to 5 days too.

After the expiry, the database backup tapes should go to scratch.

 

[sai]

we dont have DRM and no copypool too we only have DB backup.

I have one more thing here which i just saw in our environment when i did q volhistory i find few tapes with type=STGNew

i have these volumes from 2009 till date, if i delete the old tapes will there be any issue?? and these tapes also show up in q libvol as having data on them.

 

[DazRaz]

So what actual problem are you experiencing? There is no point in keeping TSM database backups forever. If you have to restore the TSM database, you will want to get the storage pool tapes back to the point they were in at the time of the database backup. That is what the reuse delay assists with. Doesn't matter if you are using DRM / copypool tapes. It is the primary pool tapes you will want to have a reuse delay on.

 

[sai]

Ralf,

We usually do full DB Backup every day and they are deleted every 7 days so the tapes then become scratch.

As we set reusedelay = 0 Days in stg, these tapes which had earlier DB Backup and now scratch tapes should be used by some other pr. but in our case they are not being used.

 

[DazRaz]

You still have plenty to scratch tapes in the library? I wouldn't worry about which tapes the library picks up. If it attempts to mount a scratch tape and that fails, it will change the tape from scratch to private.

Run this query. If it doesn't find any tapes then everything is fine. It looks for private tapes not assigned to a pool or DB backup or export.

select volume_name from libvolumes where status='Private' and libvolumes.volume_name not in (select volume_name from volumes) and libvolumes.volume_name not in (select volume_name from volhistory where type in ('BACKUPFULL','BACKUPINCR','DBSNAPSHOT','EXPORT'))

 

[sai]

I found few tapes here. so do you want me check them out and check them in again using status=scratch

when i did q content for the tapes it showed not assigned to any stg

 

[DazRaz]

I would try to find out why they are private.

q act begind=-30 search=<tape_name>

You may be able to spot why the tape is set to private. No need to check the tapes back out and in. Use this:

upd libv <library_name> <tape_name> status=scratch

This will change the status from private to scratch without checking out. Good to know why they are private before doing this though. I had some tapes recently where the write protect tab was on which caused the tape to go to private. If not fixed, they just sit in library taking up space.

 

[RaCol]

Hi sai,

tapes which are private and not assigned to a storage pool are often tapes which TSM set to this state to prevent a reaccess, because of an error during a write process. I.e. this referres to tapes which are scratch and which TSM then selects to write on them. If in this situation, if there are still no data on a tape and the write error occures TSM sets the tape to this special state and write a special message in the activity log. So check your TSM actlog for messages containing something like "... reaccess...", e.g. q act search=reaccess begind=... endd=...

Regards, Ralf

 

[sai]

Volhist

Hi sai,

tapes which are private and not assigned to a storage pool are often tapes which TSM set to this state to prevent a reaccess, because of an error during a write process. I.e. this referres to tapes which are scratch and which TSM then selects to write on them. If in this situation, if there are still no data on a tape and the write error occures TSM sets the tape to this special state and write a special message in the activity log. So check your TSM actlog for messages containing something like "... reaccess...", e.g. q act search=reaccess begind=... endd=...

Regards, Ralf

I dont really have logs for these false private tapes as we only maintain logs for 30 days. so i did keep them back into scratch lets see how it goes. Do you guys have any solution or reason on why TSM skipped few of these tapes from writing data on them. Ex: TSM picked up first 0-1600 and wrote data to them, then it left 1601-1955 as scratch and starting writing data on 1956 and so on. these tapes were never used by TSM

http://adsm.org/forum/showthread.ph...picked+0-1600+wrote+data+them,+left+1601-1955



i have one more thing here when i do a q volhist it gives me a bunch of tapes with few having type=STGNew, type=STGDelete, type=DBBackup. I can understand what it means by DBBackup where it tells DB is backuped on these tapes. What does it mean by STGNew and STGDelete. can i have some info on volhist which would be really helpful.

 

[diogopiui]

i have one more thing here when i do a q volhist it gives me a bunch of tapes with few having type=STGNew, type=STGDelete, type=DBBackup. I can understand what it means by DBBackup where it tells DB is backuped on these tapes. What does it mean by STGNew and STGDelete. can i have some info on volhist which would be really helpful.

Hello Sai,

The STGNEW and STGDELETE info on Volhist, indicates when a volume where "inserted" to storage pool and when it was deleted from there.

Regarding the scratch tapes issue, can you make sure the tapes are really inside the library and TSM are able to reach them? Anyway, after checking for the tapes on the library, I would run an audit process to update the syncronize TSM with Library Inventory.

Regards, Diogo

 

[sai]

Hello Sai,

The STGNEW and STGDELETE info on Volhist, indicates when a volume where "inserted" to storage pool and when it was deleted from there.

Regarding the scratch tapes issue, can you make sure the tapes are really inside the library and TSM are able to reach them? Anyway, after checking for the tapes on the library, I would run an audit process to update the syncronize TSM with Library Inventory.

Regards, Diogo

Hello Diogo,

Thanks for the info we cannot run audit library unless it is a production issue. i will do it later. I have one more think to clarify i think TSM data back all the info about volume info, is it still necessary to backup volhist file??

Regards,

Sai

 

[diogopiui]

Hello Sai,

An audit operation with checkl=barcode in a library with 3000 tapes will take 1 hour tops, so I guess it is not a big problem to run it. Yes, TSM back up all volume info. I normally perform a backup from volhist and devconfig to an external storage in order to make easy the TSM DB restore in case of DR, as volhist will show me the volumes that contains the DB Backup.

Att,
Diogo

 

[esiole]

Hi

upd vol as scratch for the one it doens't work, then run consoleadmin with mountmode it will tell you what is the issue and then will put it back as private.

Then you can take appropriate corrective action and have your tapes back to normal operation.

Regards
Esiole