Eseutil – Part 2: Eseutil Switches

If you would like to be notified of when Jaap Wesselius releases the next part in this article series please sign up to our Real-Time Article Update newsletter.

If you would like to read the first part in this article series please go to Eseutil – Part 1: Database Technologies.

Offline Defragmentation of a Database

In the Exchange 5 timeframe quite a lot of customers implemented an offline defragmentation of their Exchange databases as part of their monthly maintenance cycle. And to be honest, this wasn’t a bad idea (in those days that is). Microsoft has made tremendous improvement in the ESE database engine, so there’s absolutely no need to perform an offline defragmentation as part of the monthly maintenance cycle. But when do you perform an offline defragmentation? Well, after you’ve moved a large number of database (or a large amount of data) to another mailbox database.

Imagine you have a 200 GB mailbox database and you move 80 GB of mailboxes to another mailbox database. When the retention time of the deleted mailboxes has passed you will have 80 GB of free space in your mailbox database. There’s a process called online maintenance on the mailbox server, and this online maintenance is responsible for deleting messages and mailboxes that are past the 14-day or 30-day retention time. The online maintenance also “defragments” the database internally to make it more efficient, but it doesn’t shrink the database file size. Therefore in this example the database file will remain 200 GB in size, while actually only 120 GB is used!

To shrink the database to 120 GB an offline defragmentation needs to be performed. But what is actually happening when an offline defragmentation is performed?

  1. First of all, the mailbox database needs to be dismounted, so you’re facing a certain downtime
  2. A new, temporary database is created and this database gets a random name like “TEMPDFRG5268.EDB”
  3. ESEUTIL start copying data from the old database to this temporary database. So, in the example mentioned above “only” 120 GB is copied to the temporary database
  4. When all data is copied to the temporary database the old database is physically deleted from the disk
  5. The temporary file called “TEMPDFRG5268.EDB” is renamed to the name of the production database, for example “Mailbox Database 2563992651.edb”

Figure 1: Performing an offline defragmentation.The temporary database is clearly visible

This process can take quite some time. As a rule of thumb I normally use a processing speed of 5 to 10 GB per hour of actual data (on Exchange Server 2003). So the 200 GB Mailbox Database in this example has 120 GB of actual data, so it can take up to 12 hours to complete. But things are improving, with Exchange 2010 I have seen offline defragmentation with speeds up to 45 GB per hour. 120 GB will take somewhere around 3 hours to complete.

Offline degragmentation creates a new mailbox database with new signatures and so on. Therefore, it is no longer possible to recover data from earlier log files. You have to create a new full backup immediately after performing an offline defragmentation using ESEUTIL!

Since an offline defragmentation creates a new Mailbox Database this is not something that can be done easily on a CCR cluster (Exchange 2007) or on a DAG (Exchange 2010). The best option here is to create new mailbox database and move all mailboxes from the ‘old’ defragmented Mailbox Database to the newly created Mailbox Database. When finished delete the old Mailbox Database and you’re done.

Repair a Database

It can happen, although rare, that your mailbox database gets corrupt after a server failure. If you have a CCR Cluster (Exchange 2007) or a DAG (Exchange 2010) you should be fine since the 2nd copy of the mailbox database will take over. But on a single server this can be problematic. If you cannot restore from a backup and you have no other options (even calling Microsoft Product Support might be better than ‘playing around’ with the repair option!) you can consider repairing the mailbox database using ESEUTIL /P.

Using ESEUTIL /P is a destructive operation and will ALWAYS result is a certain loss of data, but unfortunately it’s not possible to predict how much data is lost.

The Mailbox Database is not a relational database like SQL Server (where all tables are predefined depending on the application you’re using) but it’s actually a Binary Plus or B+ Tree. The Database consists of multiple trees (can be thousands of trees) and every tree contains pointers and pages with data. ESEUTIL /P will check all trees and all pointers and if an inconsistency in a pointer is found it is deleted, regardless of the data the pointer is pointing to.

When ESEUTIL /P has finished you’ll end up with a database with missing pointers (and you cannot predict how many pointers will be missing) and therefore missing data. Also because of the missing pointers the database trees will not be contiguous anymore which can result in decreased performance.

Therefore it is recommended to perform an offline defragmentation (which will create a brand new Mailbox Database!) immediately after repairing a Mailbox Database using ESEUTIL /P.

But wait, there’s more. ESEUTIL repairs the Mailbox Database on a low level, so it repairs all tables, indices and pointers within the Database file. But ESEUTIL doesn’t understand things like mailboxes, folders, messages etc. After repairing and defragmenting your database after a corruption you have to scan (and fix) it on a logical level using ISINTEG. For ISINTEG to run properly, the Mailbox Database has to be on its original location.

When you run ISINTEG (ISINTEG –fix –test alltests) you will see numerous messages. Just repeat running ISINTEG until everything is fine and you don’t see any error messages.

Figure 2: Running ISINTEG on an Exchange 2003 Mailbox Server

Please be aware that ISINTEG is going to be discontinued in Exchange Server 2010 Service Pack 1. Its functionality is replaced by a new cmdlet: New-MailboxRepairRequest.

If you want to make absolutely sure that you’re 100% safe you can even think about moving the mailboxes in this particular Mailbox Database (which you just have fixed) to a brand new Mailbox Database. If you’ve done this step you can safely remove the old and repaired Mailbox Database (and don’t forget to create a new backup of this new Mailbox Database 😉


In this second article I showed you how to perform an offline defragmentation of a mailbox database and how to repair a Mailbox Database after a corruption. Be aware that the last option always means some amount of data loss. It is recommended to start a repair of a Mailbox Database when Microsoft Product Support tells you to do so. Also, after a repair you have to perform an offline defragmentation, and you have to perform a logical repair using ISINTEG.

In my next article regarding ESEUTIL I will explain a bit more about online backup, a hard recovery and performing a consistency check using ESEUTIL.

If you would like to be notified of when Jaap Wesselius releases the next part in this article series please sign up to our Real-Time Article Update newsletter.

If you would like to read the first part in this article series please go to Eseutil – Part 1: Database Technologies.

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top