ADSM-L

Re: Reducing/compressing the database

2001-04-23 20:32:35
Subject: Re: Reducing/compressing the database
From: "Thomas A. La Porte" <tlaporte AT ANIM.DREAMWORKS DOT COM>
Date: Mon, 23 Apr 2001 15:41:41 -0700
Is anybody else a little bit distressed that Tivoli's TSM
administrator needs to seek this advice from the list, rather
than from the developers of the product?

This is an issue that has been one that has generated much
discussion on and off with regards to the benefits and costs of
attempting to reorganize a TSM database, and one on which we have
never had much of a substantive response from anyone within
Tivoli, either in this forum or in the documentation of these
commands in the manuals.

I would have thought that the people at Tivoli would be the best
source for information of this type. I'm a little bit concerned
that our collective guessing and anecdotal evidence is all that
any of us as administrators have to go on.

 -- Tom

Thomas A. La Porte
DreamWorks SKG
tlaporte AT anim.dreamworks DOT com

On Sun, 22 Apr 2001, Shawn Drew wrote:

>TSM v3.7.3
>
>I have read alot on this list about reducing the database because my
>situation is pretty bad.  We have a 103 gig database that was 97% used!  I
>finally was permitted to fix the outrageous retention settings, and got it
>down to 50% utilization, but the Maximum Reduction value is still 0.  Now,
>I
>want to get the database's assigned capacity to the ibm "recommended" max
>of
>70 gigs. (This is from the ISSS last year in san diego. I was the guy that
>had an 80gig db in one of the seminars) From reading this list, it seems I
>have a few options, but could not determine the best route.  Down time IS a
>factor for this.   The performance on this machine, for restores, is
>dramatically slower than on other machines, and since it seems all else is
>almost equal, I am assuming its the db size.
>First of all, my reason for doing this is to get better performance on my
>restores.
>
>So,  will defragging the database really improve my restore times? seems
>pointless otherwise.
>
>It seems my options are:
>
>- dumpdb/loaddb - I read some horror stories of this, and really hesitate
>on
>it.  Also, it seems the loaddb takes very long, from other people's
>experience  (2 days for a 40gb db? I think I read?)
>
>- unloaddb/loaddb - The only difference I can find with this and the
>previous one is that it defrags the database.  And it seems that the loaddb
>portion is the same, and is subject to the same unreliability and time
>problems.  (This is the one described in the manuals to solve my situation)
>
>- Richard recommended the backup db/restore db options over the
>dumpdb/loaddb because it is more reliable and faster.  Does this also offer
>the defrag benefit?  And how long would it take?
>
>- Migrate all the client nodes one by one to other machines with
>import/export.  Kill and rebuild TSM and the db and move everything back.
>This seems like the one with least downtime. which may be the best option
>and least risky.  But it will take a LONG time, and strain my other boxes.
>
>thanks
>shawn
>
>___________________________________________________________
>Shawn Drew
>Tivoli IT - ADSM/TSM Systems Administrator
>shawndo AT tivoli DOT com
>