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:[EMAIL PROTECTED]] Sent: Saturday, January 18, 2003 12:00 PM To: [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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:[EMAIL PROTECTED]] >Sent: Friday, January 17, 2003 4:31 AM >To: [EMAIL PROTECTED] >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 >
