Open Discussion: Steps to Recover an Exchange Database after Dirty Shutdown

Recover & Repair Exchange Database from Dirty Shutdown

Exchange Server Database is the base of Microsoft client-server architecture and plays a vital role of hub and essentially required for Microsoft email-client platform. Damage or corruption Exchange database is quite complicated task but it may happen and when it does so you must have to recovery it immediately. This blog has written-up to describe you, the recovery of such damaged Exchange database.

Log files and its vital role in Exchange Database

Log files are similar to the bank passbook which contains all the activities performed on Exchange Database. Log files are essential part for Exchange Server and manage & maintain records of all the modification done on Exchange Server Database. These files play a vital role for Exchange Server database’s smooth working and whenever a new entry is come to store in Exchange Database it will register in log files first then bring forward to store in database.

Exchange Database Administrator is liable for proper maintenance of Log file and he must take periodic backup of Log files and cannot delete it permanently from Exchange server. Log files does have certain file size and whenever a log fill reaches to its limit then Exchange Database Administrator need to create a new log file to store the activities of Exchange server database. Log files are the asset of Exchange server database and need to restore from an older version.

What is Dirty Shutdown?

In layman’s words when CPU is busy to execute a process and at the same time user forcefully shut down the program by pressing CTRL+ALT+ DEL or from task manager it will lead dirty shutdown state. Dirty shutdown stage is always being the reason of damage or corrupt Exchange Database.

Log file and Clean &Dirty shutdown state

Technically Log files play a lead role in shut down states. By check Log file status Exchange Administrator can find out the proper or dirty shutdown state. On restart the Exchange server database if you find log files detached with database file then it is due to clear shutdown state but when you find log files attached with database file after restart the system then it will be the clear indication of dirty shutdown state and now you have to detach the log file from database first by replaying available log files and then proceeds to other task.

Affects of Dirty shutdown error

In affect of dirty shutdown state Exchange database files leads to damage or corrupt and become inaccessible for the user.

Recover dirty shutdown error

By execute Eseutil/k you cannot resolve the dirty shutdown error and you may get following messages:

  • Error: database was not shutdown properly
  • Operation terminated with Error-550
  • Exchange is unable to mount the database that you specified

Initially verify that whether Exchange server is in clean shutdown state or in dirty shutdown state. To check this status run the following command from Command Prompt.

Eseutil /mh “Path of the database”

You will get result on screen and if database shows as “Clean Shutdown”, then database is consistent and log files are detached from it. If database states “Dirty Shutdown”, then it means database is still attached to the log file and is inconsistent.

Now you can follow these methods to resolve Dirty shutdown state:

Solution1. If Database is consistent with Clean Log files
If the log files are in clean state, a soft recovery can resolve the error. In soft recovery, after an unexpected stop of the database, transaction logs are replayed to re-mount the database. Run the following utility for soft recovery database
And then, run following command for soft recovery
eseutil /r enn /L[path to log files] /s[path to checkpoint file] /d[path to database file] /i

Solution2. If Log files are not in clean state or are unavailable

If log files cannot be accessed, then hard database recovery must be performed. In this recovery, the transaction log files are replayed by restoring the database from online backup. If a valid and recent database backup is available, EDB, LOG and STM files can be restored from it. Once the process completes, automatically, a file called ‘restore.env’ will be created in a temporary folder by the name ‘C:\Temp’.
Here is the syntax for hard recovery: Eseutil /cc “Path of the restore.env containing folder”. Once the entire procedure completes, the temporary folder that contained restore.env will be empty.

3. If a valid backup isn’t available
If none of the above methods is possible, then use ESEUtil as follows: eseutil /p
And click ‘OK’ to start process. When the process ended, run eseutil with \mh switch to check database consistency again. This time, the shutdown should be clean. Defragmentation of the database now should resolve the error.

Offline Defragmentation

As a last step, database defragmentation is done to arrange the database on the server and unused pages are removed to reduce disk space. A new, compact database is created that is free of old data and unused pages. The syntax used is:eseutil /d Database_Name

Proposed Solution

If you willing to use a method other than ESEUtil or simple process to recover exchange database from dirty shutdown state then use Voimakas Exchange EDB Recovery software It repairs severely damaged EDB file and extracts all data item from it. This proficient application is compatible with MS Exchange 2016, 2013, 2010, 2007, 2003, 2000.

Leave a Reply