1. Please help support our sponsors by considering their products and services.
    Our sponsors enable us to maintain high-speed Internet connection and fast webservers.
    They support this free information and knowledge exchange forum service at no cost to you.

    Please welcome our latest sponsor Tectrade . We can show our appreciation by learning more about Tectrade Solutions

TSM DB Question

Discussion in 'TSM Database' started by ILCattivo, Nov 29, 2017.

  1. ILCattivo

    ILCattivo ADSM.ORG Member

    Joined:
    Jul 9, 2013
    Messages:
    104
    Likes Received:
    2
    Location:
    Oxford, United Kingdom
    So, for my sins I have been tasked with attempting to reduce the size of a TSM DB. Here's the problematic situation though.. <GULP>

    Platform = AIX
    TSM Ver - 6.3.3 <- EOS I know..!!
    DB2 Ver = 9.7

    TSM has been handling the DB Re-organization daily and has been completing successfully.

    Tables excluded from TSM based Re-org are :-

    ARCHIVE_OBJECTS
    BACKUP_OBJECTS
    BF_AGGREGATED_BITFILES
    BF_BITFILE_EXTENTS

    Now, here's where it starts to get a bit ugly...

    • TSM DB Size is at 96-97% capacity
    • No further physical storage available to increase the capacity.
    • Not enough available free capacity to run Offline re-org. Its fails stating as such...
    • Removal of large file spaces (18+ TB) makes no difference to TSM DB size or shrinkage.

    So, what are my options here?

    I was thinking along the lines of Backing up the database (To another disk).. and going down the dsmserv cmd route of removing it and blowing it away to make the available space back to 100%, but would the restore of the DB still place back all of the unwanted rubbish and not restore it clean? What would be the procedure for doing this if it were to work?

    Thoughts please if I may?

    Thanks
     
  2.  
  3. marclant

    marclant ADSM.ORG Moderator

    Joined:
    Jun 16, 2006
    Messages:
    2,641
    Likes Received:
    372
    Occupation:
    Accelerated Value Specialist for Spectrum Protect
    Location:
    Canada
    I'd upgrade to a current release first because many changes have been done to deal with DB growth and reorg. Latest 7.1.7.x (or 7.1.8 if you are ready for the switch to SSL, read the ReadMe if you do).
     
  4. marclant

    marclant ADSM.ORG Moderator

    Joined:
    Jun 16, 2006
    Messages:
    2,641
    Likes Received:
    372
    Occupation:
    Accelerated Value Specialist for Spectrum Protect
    Location:
    Canada
    The restore will restore what was backed up. DB2 doesn't know it's rubbish until it actually goes through the reorg.
     
  5. ILCattivo

    ILCattivo ADSM.ORG Member

    Joined:
    Jul 9, 2013
    Messages:
    104
    Likes Received:
    2
    Location:
    Oxford, United Kingdom
    Thanks

    Just a bit nervous doing any kind of server ver upgrade with a DB at that size %. Like you said though I know they introduced better DB size handling in the more recent v7.1.x & 8.1.x versions.
     
  6. marclant

    marclant ADSM.ORG Moderator

    Joined:
    Jun 16, 2006
    Messages:
    2,641
    Likes Received:
    372
    Occupation:
    Accelerated Value Specialist for Spectrum Protect
    Location:
    Canada
    Well, the key is to have a good database backup before starting any procedure, doesn't matter if it's an offline reorg or a software upgrade.
     
  7. RecoveryOne

    RecoveryOne ADSM.ORG Member

    Joined:
    Mar 15, 2017
    Messages:
    65
    Likes Received:
    7
    Have you looked at this page?
    http://www-01.ibm.com/support/docview.wss?uid=swg21452146

    Was your server upgraded from 6.1 to 6.3.3? If not you may be able to reclaim some space. Heck, just give that page a good once over, there is a section talking about "If your database backups are stored in FILE device classes, determine whether there is sufficient space for the reorganization on the file system that is accessed by the Tivoli Storage Manager server". There's a handy Perl script (run as the tsminst1 user) however can't for the life of me find the link at this moment...Not sure if it will work on 6.3.3 however.
    Why not use that disk as your temp space?

    Other options:
    Can your SAN team give you a temp lun to bring in to use as your reorg space?
    You are running AIX... is your rootvg mirrored (please say yes)? Do you have an altdisk (please say yes :) )? Like rootvg on hdisk0 and hdisk1, while your altdisk is hdisk2 ? Can you destroy any data on hdisk2, setup a vg/lv/fs on it and tada, there's your reorg space. (Full DB backup is a given, why I'm thinking a single hdisk may accomplish your goals).
    Some thing else if you only have a rootvg mirror and no altdisk: Always make sure you have a mksysb of the rootvg (nim server or dvdram) break your rootvg mirror....bring hdisk1 in as I stated above and run that way. Once reorg is finished - remove hdisk1, bring it back in and re-mirror your rootvg. This is slightly more risky than any of the other options I can think of for a reorg. Just in this case you could lose everything (OS + TSM) why I recommend a mksysb that captures the entire rootvg.

    And any time I do a reorg on the prod boxes there's always that butterfly in my stomach. I'm sure the seasoned TSM and DB2 admins are used to it by now!
     
  8. RecoveryOne

    RecoveryOne ADSM.ORG Member

    Joined:
    Mar 15, 2017
    Messages:
    65
    Likes Received:
    7
    Ok so I found the script I was thinking of. Its actually under the 7.1.1.200 tech note. I'd check with IBM to see if the script could be ran against a 6.3.3. Here's the link to the tech note:
    www-01.ibm.com/support/docview.wss?uid=swg21683633
    The note does mention 6.2 and 6.3...but it could just be a copy and paste on IBM's part.
     

Share This Page