Thought I'd add the following info that William posted 2 weeks ago. Bruce
-----Original Message----- From: William Lefkovics [mailto:[EMAIL PROTECTED]] Sent: Friday, March 15, 2002 4:51 PM To: MS-Exchange Admin Issues Subject: Regular offline defrags: definitive answer I guess Ed is not busy enough these days, so he took time to answer very difinitively why regular offline defrags with eseutil is totally unnecessary with Exchange. It is fairly thorough, a good read, and what we have seen posted here before: -----Original Message----- From: Woodrick, Ed [mailto:[EMAIL PROTECTED]] First in looking at the arguments, it helps to understand what you are arguing. Somewhat as stated, your team is right defragmentation should be done on a regular basis. It reduces the number of extensions on messages, but more importantly makes it faster and easier to find free space to store the messages. Exchange's database is just like any current art database. It's a transaction oriented, journal led write database. Nothing really spectacular about it, regular database maintenance is all that is really needed. So you can easily go to a DBA and get suggestions on how to best care for a database. In most large database products, take SQL for example, as you create a database, you give it an initial size and then specify if the database is extensible or not and if so, how big is an extension. A common default that I use is 50MB for the initial size and 5MB extensions. Then on a regular basis, the database should be defragmented, and then, once in a blue moon you might want to reload the database, although it's not often done anymore. That's the same with Exchange, you want to defragment the database regularly and then reload it on a extremely rare, probably never basis. Sounds good? Install Exchange 5.5 and let it do it's thing and that's what you've got. Nightly, the system makes two runs through each database to defragment it. It also runs through each page of the database to make sure that the checksum is correct as you perform a backup. And I believe that another process goes through and validate the structure periodically. So why run eseutil/d? Well, when I was talking about databases growing, noticed I never said shrinking. SQL doesn't shrink a database, neither does Exchange. Biggest reason is because there really isn't a need for it in most cases. How many people hear of their total storage decreasing? It's usually at least a 5-10% a year increase. But, there are situations where indeed your database could decrease dramatically. That would be if you put a new storage policy into effect, although with the dumpster it could be a few weeks before the messages are actually deleted and SIS can also impact it. Or if you've added a new server and moved users to it. There are a variety of reasons why you would have gained a lot of white space in your database. The question that you need to ask yourself is "are you going to use it again?" If you've deleted some users or objects and you've created 1-% additional white space, just how long do you expect it to be before the space fills back up? If it's a few months, don't worry about it. I tend to make a few GB or 10% of the total store, whichever is higher, the number at which I even start thinking about repacking. I saw last night that I've got 50MB of white space in one of my DBs. It's not even on the radar screen to be compacted. If I had 5GB of white space on a 50GB database, then I might start looking for a window to compact it. But remember that it's going to take a few hours of downtime to do it. Eseutil /d is really a misnomer, a hangover from earlier days. For Exchange 5.5 and later, it really should be eseutil /c or "compact" While it does an applied defragmentation, the database is seldom fragmented, because it is defragmented twice every evening. Oh, and if you do compactions on a regular basis to the same disk, you are probably going to get some ugly NTFS fragmentation. (And yes Daniel, if you compact your database, the system is going to take extra overhead to have to expand the database. And compared to writing a single object, I suspect that it's a rather lengthy process. Okay, it's probably a hundredth of a second, but when you compare it to ill-advised behavior like compacting regularly, at least it make sense) But the real reason why not to do it is like everyone has said, there is nothing to be gained, and a lot to be lost. It is NOT REQUIRED and NOT SUGGESTED to obtain 99.999% uptime. Matter of fact, doing it brings you down to about 99.5% uptime, just taking 4 hours per month. As to making an Exchange Server reach 100% uptime, the equation is pretty simple.... Keep the Hands Off!!!!! (This assume nightly full backups and verification that the backup ran --VERY important!) Sorry folks, not enough time to give you the long version :-) List Charter and FAQ at: http://www.sunbelt-software.com/exchange_list_charter.htm List Charter and FAQ at: http://www.sunbelt-software.com/exchange_list_charter.htm
