Repairing an Exchange 2003 storage group after a dirty shut down


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

This entry was posted in Exchange, Microsoft and tagged , . Bookmark the permalink.

3 Responses to Repairing an Exchange 2003 storage group after a dirty shut down

  1. ericjohnson says:

    Thanks for putting the useful information about ESEUTIL tools. It’ll help the users to run the utility correctly and fix the Exchange database files. Recently, we’re also faced the database dirty shutdown problem which corrupted our database and hanged us from using any email in our inbox. Then, with the help of a third party program, we successfully rebuild and mount the database to MS Exchange server. here is the link of that tool: http://www.exchangeserver.pcrecoverytools.com/

    Although eseutil /p repair command is a useful inbuilt utility but always does not work accurately and gives the data less than our expectation. In such cases, when inbuilt utilities do not work, it is good to go with a third party program.

    Note: I would suggest to make backup of your databases regularly !

    Like

  2. Thanks for sharing the information on Exchange 2003 shutdown issue. I am going to bookmark this article for future. I ran ESEUTIL /P command to repair my Exchange EDB file but no luck. I did Google and found SysTools Exchange Recovery tool to repair EDB file. Finally, the issue has been fixed. Please visit the link https://www.systoolsgroup.com/exchange-recovery.html and free download to fix the issue in EDB file.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s