I just had to go through this process at a client, who is running Exchange 2003, and haven’t had to do this in a few years.  Since I mainly focus on design\architecture work I don’t do troubleshooting or system down issues too often.  I ended up spending a bit of time refreshing myself with ESEUTIL and thought I would document my findings.

Whenever there is an unmountable database in Exchange there are some key questions to ask:

1.       When was your most recent GOOD backup? 

·         We might need to restore from it and then try to replay the log files.

2.       Was this DB in its own storage group or one shared by other DBs?

·         If the database is in a shared SG with other DBs that are on-line they might need to be taken off-line during the recovery steps.  So to be safe, if possible move the mailboxes out of this SG before dismounting the “good” databases.

3.       Do the LOG files exist or were they lost? 

·         If they exist we might be able to replay them to bring the database up to date with ESEUTIL /R.  If they do not exist then your recovery options are limited.  If they might be corrupted the /ML switch can be used to test for corrupted log files.

Database Recovery Steps

If you have the LOG ESEUTIL /R might get you back up and running with very little chance for data loss.

1.       Run ESEUTIL /mh <path to database> (dump headers)

·         This checks the status of the database , it should show dirty shutdown

2.       Run ESEUTIL /R <DB ID> /D<Path to database>
Example: ESEUTIL /R E00 /D”D:\Exchange Data\SG1\SG1DB1.edb”

·         If multiple DBs were in the storage group you will need to add the /i option if some of them are also in a dirty shutdown state.

3.       Run ESEUTIL /mh <path to database> (dump headers)

·         This checks the status of the database , it should show clean shutdown

4.       If the state still shows dirty shutdown you will need to repair the database, see steps below

Database Repair Needed

Below are probably the steps needed to fix the database, but with possible data lost, and get it back up and running ASAP probably.  To not lose any data, the most recent log files are required and the ESEUTIL /R needs to run successfully.  If you do carry out these steps keep the copy of the EDB & STM files, from step #2 below.  If data is lost you might be able to restore data from them with Ontrack PowerControls directly or similar tools

1.       Run ESEUTIL /mh <path to database> (dump headers)

·         This checks the status of the database , it should show dirty shutdown

2.       Copy current the EDB & STM files to another drive\server

3.       Move all the files from mdbdata folder, for this DB, except the .EDB and .STM files to a temp folder

·         Do not delete the .CHK or LOG files, we might need\use them later if data was lost

4.       Run ESEUTIL /p <path to database> (repair) on the EDB
Example:
ESEUTIL /P c:\exchsrvr\mdbdata\DB1.EDB /Sd:\exchsrvr\mdbdata\DB1.STM /Te:\TEMPREPAIR.EDB

·         This command line will repair DB1.EDB located on C: along with its matching .STM file located on D: and will put the temporary file on the E: drive.

·         It require 25% of free space and runs at ~3 GB/hr

·         Quick tutorial here on the /P option

5.       Run ESEUTIL /d <path to database> (defrag)

·         Besides defragging the database, this will fix corrupted index issues that may be caused by the /P command

·         This requires 110% of free space and runs at ~4 GB/hr

6.       Run ESEUTIL /mh <path to database>

·         This checks the status of the database , it should show clean shutdown

7.       Make another copy of the current EDB & STM files

8.       Run ISINTEG -s <server> -fix –test AllTests

·         When running this commend you will be shown all databases on <server> and their current status.  Select the database that you ran the above steps on

·         Runs at ~10GB/hr

Good articles\posts on this topic and the source for some of the info above:

Repairing Exchange databases with ESEUTIL – when and how?

Using ESEUTIL to recover and repair exchange databases with dirty shutdown state