Repairing an Exchange 2007 Database

As system administrators, there is nothing quite like the feeling you get when you are staring at a downed exchange server. Honestly, there is very little that would impact end users more than the loss of email. Unwittingly, I have even had a whole DC go down for several hours unnoticed just due to the fact that email and Internet was still working.  Losing exchange is a big deal.

All versions of exchange, despite their overwhelming complexity, have several tools available to help one repair and/or recover an exchange data store. Today’s post will mainly focus on Exchange Server 2007, but again, a lot of these tools are available with 2003 and will be available in the 2010 version.

Before we begin this, I think we are all working under the assumption that there is a recent and intact backup available. If there isn’t, I really must say – all bets are off. Backup! Backup! Backup…not doing so is playing with your career!

More often than not, the first tool you will use when dealing with Exchange database issues is the Database Recovery Management Tool. This tool can be found under the toolbox section of the exchange management console and will offer a lot of insight into why the database has failed. In worst case scenarios, it may even be able to recover the database to a working state.

Some of the functions of this tool are:

• to verify databse and transaction log files 
• to analyze log drive space
• to reset the log generation number
• to repair a database
• to show database-related event logs
• to merge or copy mailbox content
• to set the database can be overwritten by restore option.

One word of caution here though – the repair database option can and often does result in permanent data loss. Only use this option if you do not have a backed up database to restore from and this is your only option.

Another handy tool that can be used to work with your exchange databases is the Database Troubleshooter tool.

This is handy when you are faced with a database that will not mount, or there is some inconsistency in the log files due to them being excessively long or from a drive space issue.  The tool is pretty straightforward and will systematically test the database to identify issues stopping a successful connection and/or mounting.

The third tool that can be used is the venerable Exchange Server Database Utility often known as the ese utility.  The tool is located in the default Exchange install folder in the bin directory and can be used in many ways from the command line to repair or recover and exchange database. Again, another word of caution is needed here. The ese utility can result in data loss, so your first and best bet is to always try restoring from backup first if at all possible. In fact, the repair function in the (the /P switch) ese utility works by going through pages in the database that seem unrecoverable and simply discarding them to bring the database back into a consistent state. If that sounds a little scary too you, I am glad that you are fully comprehending the gravity of that switch. The /R switch will attempt to recover the database by rolling back or updating database files by replaying the transaction log. This, while time consuming, often works well in fixing the information store up.

One thing that should be mentioned at this time also – to use the eseutility, you have to dismount the database first.

Use the following command from the exchange management console to do this.

Dismount –Database –Identity “DBName\First Storage Group\Mailbox Database”  After running any of these commands, it is also advisable to use the /D switch to defragment the database as repair operations will often leave large areas of white space.

Finally, Exchage 2007 has a tool known as the integrity checker (isinteg.exe). This tool is effective in fixing relationships between databse tables such as the “public Folders” and mailbox tables. It runs at the logical schema level and because of this attempts to repair inconsistencies at the application level.   This tool is designed for disaster recovery and is often run after you have recovered a mailbox store using the eseutility or from backup.

Unfortunately, Exchange repair is never a fast or particularly fun task, but knowing and practice using the tools above will help alleviate the pressure of production server failures. Set up your own exchange environment, populate it with some garbage, and then practice breaking and recovering the database as many times as you can stomach. Try using a hex editor to cause corruption in the database and see how these tools work.  Trash it and see what you can do!

Good Luck.