TSM DB Question

[ILCattivo]

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

 

[marclant]

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

 

[marclant]

but would the restore of the DB still place back all of the unwanted rubbish and not restore it clean?

The restore will restore what was backed up. DB2 doesn't know it's rubbish until it actually goes through the reorg.

 

[ILCattivo]

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

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.

 

[marclant]

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.

 

[RecoveryOne]

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.

I was thinking along the lines of Backing up the database (To another disk).

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!

 

[RecoveryOne]

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.

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.