Shawn, with the database of this size you might evenconsider splitting it on two TSM instances. There are advantages and drawbacks coupled with that, but it works. >> - Migrate all the client nodes one by one to other machines with >> import/export.� I did it when I moved from OS/2 to NT Server, and it worked flawelesly. It is even easier if you have either enough tape ressources, or you can afford temporarily disk space to export/import single clients. regards Juraj salak -----Urspr�ngliche Nachricht----- Von: Shawn Drew [mailto:[EMAIL PROTECTED]] Gesendet am: Sonntag, 22. April 2001 08:30 An: [EMAIL PROTECTED] Betreff: 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 [EMAIL PROTECTED]
