Roger, I agree with you on your point; however, there is one consideration
which we have found requires and unload/load. We do a lot of delete
filespaces because we have a lot of server migrations and are required to
keep the old image for 1 year, then delete it. This is also true for
filespaces converted to unicode. So, I have hundreds of very large
filespaces that have been delete, bloating my TSM database to 134GB today.
Less than half of this database is probably good data. For the 20GB
database on fast hardware, probably makes no sense to reorganize. My 134GB
database now takes 90 minutes to backup on a good day (no other activity)
and 145 minutes on a heavy activity day. I will cut my backup time to less
than an hour every day and avoid the collision with my other processing.
So, I say a reoganization depends on what benefit you are going to get that
is actually long term. Deleted filespace recovery is longterm. Backup time
is long term, in this example.
Paul D. Seay, Jr.
Technical Specialist
Naptheon Inc.
757-688-8180
-----Original Message-----
From: Roger Deschner [mailto:rogerd AT UIC DOT EDU]
Sent: Saturday, January 18, 2003 12:00 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: database reorganisation
I'm with Dwight. The correct answer is "never". And I'm one of those people
who is constantly tweaking the disk configuration, comparing different
mirroring schemes, evaluating RAID thingies, adjusting buffer sizes, and so
on, but I never unload/load my database.
An ADSM/ITSM (recursive acronym) database is naturally fragmented to a
degree. It reaches a steady-state, and then it doesn't get any worse.
Expiration will create enough space for new objects to be added. You can
unload/load, and you can achieve a performance boost, but only for a while.
It will return to its natural steady-state of fragmentation after some
number of weeks or months. Then you'll have to do it again.
An unload/load DB operation is costly - FOR YOU! It requires considerable
downtime, no small amount of risk, quite a bit of your effort and time for
oversight, and a whole lot of just plain angst. Then after a while you have
to do it all over again. It becomes a treadmill.
Let's say for discussion it improves performance by 25% right off the bat,
but that's only a temporary improvement. If I spend the same amount of time
lobbying my employer to get a 25% faster server computer with 25% more disk
space, so it can run a naturally fragmented database acceptably fast, that's
a permanent improvement.
I would only consider it in a case where something had happened to
drastically reduce the number of objects in the database - such as removing
a group of very busy nodes, or splitting a server into two servers.
So, it's a downtime issue - our end-users expect to be able to restore their
files 24/7. It's also a "labor relations" issue, between us, the **SM
administrators, and our employers. It's much more worthwhile to compensate
for the inevitable degree of fragmentation with hardware, compared to the
cost to your sanity, blood pressure, and marriage, of periodic unload/load
db operations. Hardware is cheap compared to those other things that really
matter to us, and that's why I *NEVER* unload/load db.
Roger Deschner University of Illinois at Chicago rogerd AT uic DOT edu
Life is too short to drink cheap beer.
On Fri, 17 Jan 2003, Cook, Dwight E wrote:
>If you want to remove a DB volume because you aren't using that much
>space based on the Pct. Util., but you can't because the max reduction
>isn't large enough.
>
>Be it good or bad, I can't say but we've had 10 TSM servers (most are
>going on 7 years old now) and the only place I've ever unloaded &
>loaded the TSM data base has been in our test environment... just to
>see what goes on... (our TSM db's are between 8 GB & 32 GB's)
>
>Dwight
>
>
>
>-----Original Message-----
>From: Francois Chevallier [mailto:Francois.CHEVALLIER AT CCMX DOT FR]
>Sent: Friday, January 17, 2003 4:31 AM
>To: ADSM-L AT VM.MARIST DOT EDU
>Subject: database reorganisation
>
>
>What are the best criteria to know if it's time to reorganize the tsm
>database (by unloaddb /loaddbb) Sincerly
>
>François Chevallier
>Parc Club du Moulin à Vent
>33 av G Levy
>69200 - Vénissieux - France
>tél : 04 37 90 40 56
>
|
