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