I kept that one, too. -----Original Message----- From: Schwartz, Jim [mailto:[EMAIL PROTECTED]] Sent: Monday, June 24, 2002 11:57 AM To: MS-Exchange Admin Issues Subject: RE: Compacting
If you want some in depth reading about it see below. Ed Woodrick wrote this and posted to another list a few months back. <Ed comments> 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!) -----Original Message----- From: Andy David [mailto:[EMAIL PROTECTED]] Sent: Monday, June 24, 2002 2:38 PM To: MS-Exchange Admin Issues Subject: RE: Compacting Q186291 -----Original Message----- From: Abercrombie, Sherry [mailto:[EMAIL PROTECTED]] Sent: Monday, June 24, 2002 2:30 PM To: MS-Exchange Admin Issues Subject: RE: Compacting The only time you should really run an off-line defrag (aka eseutil.exe) is when you expect to regain a large amount of space after having moved and/or deleted a substantial number of mailboxes. Right William? Exchange priv.edb IS a database, do your Oracle DBA's defrag their databases on a regular basis? You should not run off-line defrags on a regular basis. Okay, I do have a question about the lovely little event ID 1221. I get about 8-10 of them every night from just before midnight to around 6AM, they almost all report the same amount of free space available except for one which will show a significantly larger amount. For example, today's logs 9 of them show 19 MB free space, one of the shows 378 MB free space. What's the REAL figure? Just wondering :S Sherry -----Original Message----- From: William Lefkovics [mailto:[EMAIL PROTECTED]] Sent: Monday, June 24, 2002 12:40 PM To: MS-Exchange Admin Issues Subject: RE: Compacting Absolutely. Now, the overall file size will not change. If a large amount of data is moved, there will be whitespace within priv.edb ready for reuse and the data will still be nicely and neatly defragged each night. Check the application event logs, which you do every morning anyway, right? You will find the maintenance results, including 1221 disclosing the amount of whitespace. It's a beautiful thing. -----Original Message----- From: Bill Beckett [mailto:[EMAIL PROTECTED]] Sent: Monday, June 24, 2002 10:34 AM To: MS-Exchange Admin Issues Subject: RE: Compacting 2000, 5.5, all versions? -----Original Message----- From: William Lefkovics [SMTP:[EMAIL PROTECTED]] Sent: Monday, June 24, 2002 1:33 PM To: MS-Exchange Admin Issues Subject: RE: Compacting Has it been a month already? Since it is a bright relational database, it runs an online maintenance process nightly by default that defrags the contents of the databases. It takes care of itself. William -----Original Message----- From: Bill Beckett [mailto:[EMAIL PROTECTED]] Sent: Monday, June 24, 2002 10:19 AM To: MS-Exchange Admin Issues Subject: Compacting Friends and astute members of the exchange list. Please forgive such basic questions but I am new to exchange. (came from lotus notes) Since exchange is essentially a database, I would assume this database gets fragmented. Is there a tool that can be used to "unfragment"? 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 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 List Charter and FAQ at: http://www.sunbelt-software.com/exchange_list_charter.htm ------------------------------------------------------------------------ ---- -- The information contained in this email message is privileged and confidential information intended only for the use of the individual or entity to whom it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copy of this message is strictly prohibited. If you have received this email in error, please immediately notify Veronis Suhler Stevenson by telephone (212)935-4990, fax (212)381-8168, or email ([EMAIL PROTECTED]) and delete the message. Thank you. ======================================================================== ==== == 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 List Charter and FAQ at: http://www.sunbelt-software.com/exchange_list_charter.htm
