Read time 5 minutes
In Exchange 2010 or any other version, it is necessary to have access to log files to repair corrupt Exchange database completely. When Exchange Server starts up, it always performs a check to verify whether the database is detached from the transaction log or not. The primary reason behind the inspection is to ensure that no transactions are left to be written to the database. However, if any database still remains attached to the transaction logs, Exchange Server automatically detaches it by replaying the available log files.
Log files can be very helpful when you need to restore the database from a previous state. That’s why it is recommended not to delete log files permanently. Moreover, when the Exchange Server is in Dirty Shutdown state, and you need to recover the database from a recent backup, then transaction logs play a vital role.
In this article, we will discuss how Exchange Database can be recovered in Dirty Shutdown state with or without log files.
Most of you might know that a transaction is a set of operations performed against the database to ensure that the Exchange Database remains intact with complete data. Each of these transactions is recorded in log files to keep track of the changes. It helps in restoring the database to its working state by rolling back the transactions if anything goes wrong.
Now, you must be thinking about how to verify whether the database is in a clean state or Dirty Shutdown state. Well, there is a way to confirm that. Following the commands, you can verify the state of your Exchange Database.
Note: Make sure you are connected to Exchange Server while running these commands.
Microsoft provides a useful in-built utility that can be used to verify the state of the database as well as to repair and restore the database.
If the database is in a Clean state, it means it has been detached from the transaction and is consistent. However, if it is in Dirty Shutdown state, it means the database is still attached to the transaction and is inconsistent. In Dirty Shutdown state, the priority is to recover Exchange Database, but what exactly is Dirty Shutdown state.
The Exchange Server database is entirely based on JET Blue engine technology, which is known as the Exchange Storage Engine. This engine uses database cache for optimizing the input-output operations to the log files. And if the database is not updated with the transaction logs, the JET engine marks the database pages as Dirty. And that’s why the Exchange database comes into Dirty Shutdown state.
There are two methods to fix the Dirty Shutdown state, depending upon the availability of log files.
So, before applying any methods, it’s necessary to verify the state of log files as well. For this, you can use:
Eseutil /ml ” log files path\log prefix”
Another method is there to repair the database. In case, if you don’t have a valid backup or the log files are inconsistent, then you can repair the database using /p switch with Eseutil. The command will be as follows:
C:\Program File\Exchsrvr\Bin>eseutil /p “C:\Exchsrvr\Mailbox Store (SERVER).edb”
On running this command, you will receive a prompt, click OK to run the command. It will start repairing the Database.
Also, once the repair process is complete, check the state of the database to ensure whether it is in a shutdown state or a clean state.
If you cannot fix the issues using Eseutil, you will have to use third-party Exchange Recovery software that can help you recover the data in every corruption situation. Kernel for Exchange Server is one such utility that is very effective in recovering the Exchange database in any situation. It has multiple features and functionalities that make it capable of recovering data from highly corrupt Exchange databases.
Fixing Exchange Dirty Shutdown state, especially when log files are missing, is a very complicated task. Although Microsoft does provide Eseutil command-line utility to fix the issue, it isn’t helpful in every situation. In this article, we have discussed how you could fix the Exchange Dirty Shutdown state with Eseutil commands. Also, we have recommended Kernel for Exchange Server, which can be used when Eseutil fails to repair the database.