I think he's busy commuting to his new client. :) ----- Original Message ----- From: "Blunt, James H (Jim)" <[EMAIL PROTECTED]> To: "Exchange Discussions" <[EMAIL PROTECTED]> Sent: Monday, March 18, 2002 4:29 PM Subject: RE: eseutil /d
Speaking of Ed's, where is Crowley? Haven't seen any posts from him lately. Jim Blunt -----Original Message----- From: Soysal, Serdar [mailto:[EMAIL PROTECTED]] Sent: Monday, March 18, 2002 1:21 PM To: Exchange Discussions Subject: RE: eseutil /d Good to have you back Ed. Serdar Soysal -----Original Message----- From: Woodrick, Ed [mailto:[EMAIL PROTECTED]] Sent: Friday, March 15, 2002 4:27 PM To: Exchange Discussions Subject: RE: eseutil /d That does sound like my argument.... 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 :-) -----Original Message----- From: William Lefkovics [mailto:[EMAIL PROTECTED]] Posted At: Friday, March 15, 2002 3:34 PM Posted To: Microsoft Exchange Conversation: eseutil /d Subject: RE: eseutil /d I remember that. Mr Woodrick was pushing the envelope there. With the whitespace taken away, Exchange would have to take back diskspace as the database began to grow again. The resources required for that would likely not be noticeable. :o) But of course he was correct. William -----Original Message----- From: Ray Zorz [mailto:[EMAIL PROTECTED]] Sent: Friday, March 15, 2002 10:06 AM To: Exchange Discussions Subject: RE: eseutil /d I remember an excellent explanation of how this will actually hurt Exchange performance by one of the Ed's. I saved it, then lost it somehow. Maybe someone still has it. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Couch, Nate Sent: Friday, March 15, 2002 10:54 AM To: Exchange Discussions Subject: RE: eseutil /d Try reading Jim McBee's book - Exchange 247. It talks about this very issue. Basically, it comes down to the view, from my reading, that "if it ain't broke - leave it alone". If you aren't seeing any errors in the Event logs that clue you into a problem with the databases don't go begging for trouble - you are likely to find it. All the best in your battle with your coworkers. Nate Couch EDS Messaging > ---------- > From: paragon400 > Reply To: [EMAIL PROTECTED] > Sent: Friday, March 15, 2002 11:32 > To: [EMAIL PROTECTED] > Subject: eseutil /d > > I have some team members here that believe that regular > defragmentation > (offline) should be done as routine maintenance. I don't share this > opinion, but I am having a hard time finding evidence to support my > belief. Does anyone know of any links that support the theory that > eseutil should not be used for regular maintenance or am I wrong and > should it be part of regular maintenance? > > Exchange 5.5 environment. > > Thanks for any help anyone can provide. > > _ _________________________________________________________________ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Archives: http://www.swynk.com/sitesearch/search.asp To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin: [EMAIL PROTECTED] _________________________________________________________________ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Archives: http://www.swynk.com/sitesearch/search.asp To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin: [EMAIL PROTECTED] _________________________________________________________________ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Archives: http://www.swynk.com/sitesearch/search.asp To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin: [EMAIL PROTECTED] _________________________________________________________________ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Archives: http://www.swynk.com/sitesearch/search.asp To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin: [EMAIL PROTECTED]
