MSExchangeGuru.com

I have been dealing with recovering exchange databases for a long time now and recently had someone contact me with a typical no backup server crash scenario.

The purpose of this article is to demonstrate a method by which “possibly” you can eliminate a repair or /p process or a restore of your Exchange database.

Now, there is no guarantee that this would work – take it as a last resort.

I am going to assume you have tried the normal process as outlined in the article:

Exchange Database Recovery – Using eseutil commands: http://msexchangeguru.com/2009/07/12/exchange-database-recovery-using-eseutil-commands/

Here, we have some pre-requisites to go through before we proceed

• You have an Exchange 2010 database in a dirty shutdown state
• You have at least 300 log files in a healthy state

First process is to make a note of which log files does the database require to make itself to a clean shutdown state

To know this, run eseutil /mh which will show you the logs required:

So here we need the logs:

E06000011B1 – Ox means the prefix of the log name

Now, try to find if you have this log file intact.

Mostly it maybe the E00.log file

In my case, I had the E00.log and E00tmp.log

Which means the server crashed when a new E00.log was in the process of being created.

Now try to perform soft recovery and recover the database.

Exchange gives you an option of lossy recovery which lets you ignore missing logs as outlined here:

Exchange 2007: Operation terminated with error -939586631 The restore environment information isn’t found or cannot be opened: http://msexchangeguru.com/2010/07/27/e2k7-restore-939586631/

So try the command:

Eseutil /r E0n /l “Log file location” /d “Database Location” /a /i

• E0n – Name of the log file sequence like E00, E01, E02 etc
• /a – This is the key. This switch will allow a lossy recovery option
• /i – will override database mismatch

If this doesn’t work, simply try the following before you decide to repair the DB.

NOTE: BACKUP ALL YOUR DATABASE and LOGS

Rename the CHECKPoint file which is E06.chk in my case

The checkpoint file remembers the last played log in our case won’t help.

Now create a newfolder – LOGS and copy all 300 logs to that location till the E06000011B1 log file

Now make a copy of “E06000011B1.log” and rename it to E00.log and place in the same location

You can use eseutil /mk “E06000011B1.log” to know the LGen number of the log

Make sure the checkpoint file is renamed.

Now run the soft recovery command again and “DELETE THE NEW E00.LOG” that you created while soft recovery is running

Eseutil /r E06 /l “NEW log file location” /d “DB Location” /a /i

This is tricky process. Read again – while the soft recovery is proceeding, you need to delete the E00.log file and once the recovery completes, the database will be in clean shutdown state.

Before mounting the database again, clear all logs in the database location so that we can start with a new set of log files and BACKUP right away.

Let’s say the database need two log files to make itself clean – E06000011B1 and E06000011B2 and you have E00.log and E00tmp.log in the logs location, simply look for E00.log and E00tmp.log number using the command eseutil /mk and rename E00 to E06000011B1.log and E00tmp.log to E06000011B2.log and make a copy of E06000011B2.log and make it E00.log which we can delete while soft recovery is running.

The reason I mentioned you need atleast 300 logs is because soft recovery is a lighting fast process and it wont let you delete the E00.log if it doesn’t have enough logs to replay to the database.

You can repeat the steps several times but – delete the CHECKPOINT file everytime or it will fail instantly.

You can contact me with questions at the Contact- US section.

Ratish Nair

MVP Exchange

Team @MSExchangeGuru

Keywords: exchange database recoevery, eseutil, Exchange database missing logs, repair exchange database.

Posted February 1st, 2013 under Database Management, Exchange 2007, Exchange 2010, Recovery. RSS 2.0 feed. Leave a response, or trackback.