The Exchange Server 2010 database format is considerably more stable than it used to be, but corruptions still can and do occur. In the event of a corrupt database, administrators have the option to either restore a backup or attempt to repair it. Unfortunately, it is not as simple as it seems. There are a few nuances you must be aware of, so it might be wise to adhere to the following words of caution.
Dismounting the Exchange Server 2010 database
Before attempting to repair a database, you must verify that it is dismounted. To do so, open the
Locate the database you need to repair and make sure that the Mounted column displays the word Dismounted (Figure 1). If the database is mounted, you can dismount it by right-clicking the database and selecting the Dismount Database command.
Figure 1. Verify that the corrupt Exchange 2010 database is dismounted.
Using ESEUTIL to repair a corrupt Exchange 2010 database
To repair a corrupt Exchange 2010 database, you should use the ESEUTIL command-line utility. You can find it in the C:\Program Files\Microsoft\Exchange Server\V14\Bin folder.
Before I explain how to use ESEUTIL, I have a few words of caution. Even though ESEUTIL does a better job of repairing databases than it used to, there is still a high probability that you will lose some data when using it to repair an Exchange database.
ESEUTIL rebuilds the database and deletes any invalid data that it encounters during the rebuild. Therefore, it is imperative that you back up the database before attempting a repair.
If you aren’t sure when the database was last backed up, you can get that information using ESEUTIL. To do so, navigate to the folder containing the database and enter the following command:
ESEUTIL /MH “<mailbox database name>”
For example, if you want to repair Mailbox Database 1337460880, use the following commands:
CD\Program Files\Microsoft\Exchange Server\V14\Mailbox\Mailbox Database 1337460880
ESEUTIL /MH “Mailbox Database 1337460880.edb”
This command displays the contents of the database header. The header displays when the database was last backed up, among other things. My header is too large to fit everything into a screen capture, but Figure 2 shows what the backup portion looks like.
Figure 2. Always verify that your Exchange 2010 database has been backed up before repairing.
Depending on the degree of corruption within the database, it might not be possible to mount it to perform a traditional backup. If that’s the case, you can perform a file-copy backup -- as long as the database is dismounted. Make sure to back up the following files:
- The database file: This file ends in an .edb extension and contains the actual mailbox data.
- The log files: Log files start with a E00 prefix and end in .log.
- The checkpoint file: The checkpoint file (E00.chk) tells Exchange which log files have been committed to the database.
Next, perform an integrity check on the database. An integrity check will help assess the extent of the damage. You may only have to perform a simple recovery (using the ESEUTIL /R command) or you might have to do a full database repair. Performing an integrity check is the best way to find out which type of operation you’ll need.
To perform an integrity check, enter the ESEUTIL /G “<database name>” command (Figure 3).
Figure 3. Use the ESEUTIL /G command to perform an integrity check on the corrupt Exchange 2010 database.
Repairing the Exchange 2010 database
You can repair a database by using the ESEUTIL command with the /P switch. As I mentioned earlier, this command almost always results in at least some data loss, and can actually introduce different types of corruption into the database. Therefore, the cleanup process you run after repair completion is just as important as the repair itself.
Before getting started, understand that you’ll need a lot of free hard disk space if you want the repair and cleanup to work properly. My general rule of thumb is you need as much free space as the database is currently consuming, plus an extra 20%. This is because the database will be physically rebuilt as part of the process.
Perform the repair by entering the ESEUTIL /P “<database name>” command.
After the repair process completes, the next thing you should do is to perform an offline defrag. A database that has been repaired may be missing internal pointers. Performing an offline defragmentation physically rebuilds the database and often re-creates some of the missing pointers. You will need the ESEUTIL /D “<database name>” command.
After the defragmentation completes, there is one more command you must run to complete the cleanup process:
ISINTEG –S <server name> -Fix –Test alltests
In most cases, this command will return a number of errors. Just keep re-running the command until all of the errors eventually go away. In my experience, you have to run the command several times.
ABOUT THE AUTHOR:
Brien Posey is an eight-time Microsoft MVP with two decades of IT experience. Before becoming a freelance technical writer, Brien worked as a CIO at a national chain of hospitals and health care facilities. He has also served as a network administrator for some of the nation’s largest insurance companies and for the Department of Defense at Fort Knox.
This was first published in June 2012