ADSM-L

Reducing/compressing the database

2001-04-22 02:44:25
Subject: Reducing/compressing the database
From: Shawn Drew <Shawn_Drew AT TIVOLI DOT COM>
Date: Sun, 22 Apr 2001 01:30:10 -0500
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
<Prev in Thread] Current Thread [Next in Thread>