Shawn,
One thing you might try: delete the DB volumes individually. When you do
that, *SM copies the data from the volume being deleted into free space on
other DB volumes. After that copy operation is complete, add that same DB
volume back in to the system. It should come in as 0% utilized and its
space should show as a potential reduction.
I've used this technique to distributed DB data evenly across several hard
drives. It's slow, but a lot faster than unload/reload, etc.
Good luck.
Tab Trepagnier
TSM Administrator
Laitram Corporation
Shawn Drew <Shawn_Drew AT TIVOLI DOT COM>@VM.MARIST.EDU> on 04/22/2001 01:30:10
AM
Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
cc:
Subject: Reducing/compressing the database
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
|
