Results 1 to 16 of 16
  1. #1
    Newcomer
    Join Date
    May 2011
    Posts
    41
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Default TSM scratch tapes issue need help

    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

  2. #2
    Member
    Join Date
    Dec 2005
    Posts
    47
    Thanks
    0
    Thanked 6 Times in 6 Posts

    Default

    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

  3. #3
    Newcomer
    Join Date
    May 2011
    Posts
    41
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Default

    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

  4. #4
    Member
    Join Date
    Jun 2008
    Posts
    94
    Thanks
    1
    Thanked 4 Times in 4 Posts

    Default

    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.

  5. #5
    Newcomer
    Join Date
    May 2011
    Posts
    41
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Default

    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.

  6. #6
    Member
    Join Date
    Jun 2008
    Posts
    94
    Thanks
    1
    Thanked 4 Times in 4 Posts

    Default

    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.

  7. #7
    Newcomer
    Join Date
    May 2011
    Posts
    41
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Default

    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.

  8. #8
    Member
    Join Date
    Jun 2008
    Posts
    94
    Thanks
    1
    Thanked 4 Times in 4 Posts

    Default

    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'))


  9. #9
    Newcomer
    Join Date
    May 2011
    Posts
    41
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Default

    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

  10. #10
    Member
    Join Date
    Jun 2008
    Posts
    94
    Thanks
    1
    Thanked 4 Times in 4 Posts

    Default

    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.

  11. #11
    Member
    Join Date
    Dec 2005
    Posts
    47
    Thanks
    0
    Thanked 6 Times in 6 Posts

    Default

    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

  12. #12
    Newcomer
    Join Date
    May 2011
    Posts
    41
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Default Volhist

    Quote Originally Posted by RaCol View Post
    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.php...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.

  13. #13
    Newcomer
    Join Date
    Sep 2010
    Location
    Brazil
    Posts
    13
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Default

    Quote Originally Posted by sai View Post
    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

  14. #14
    Newcomer
    Join Date
    May 2011
    Posts
    41
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Default

    Quote Originally Posted by diogopiui View Post
    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

  15. #15
    Newcomer
    Join Date
    Sep 2010
    Location
    Brazil
    Posts
    13
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Default

    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

  16. #16
    Member
    Join Date
    Jan 2006
    Location
    Mauritius
    Posts
    25
    Thanks
    0
    Thanked 1 Time in 1 Post

    Default

    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
    -= D\'ici de la , mais toujours a la bonne place =-

Similar Threads

  1. TSM using more scratch Tapes
    By sus in forum Performance Tuning
    Replies: 5
    Last Post: 10-07-2013, 05:44 PM
  2. Having Scratch tapes Issue...Needs to clear files from storage pools/volumes
    By ravi3010 in forum Backup / Archive Discussion
    Replies: 2
    Last Post: 03-27-2012, 11:25 AM
  3. Replies: 2
    Last Post: 03-30-2011, 08:59 AM
  4. Issue with Scratch tapes
    By ravi3010 in forum Tape / Media Library
    Replies: 2
    Last Post: 02-08-2010, 02:11 PM
  5. TSM scratch tape issue.
    By menonk in forum Tape / Media Library
    Replies: 0
    Last Post: 09-04-2006, 07:41 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •