Fix Exchange 2010 Dirty Shutdown Error with or without Logs
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.
How to Check the State of Exchange 2010 Database?
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.
- To check the state of the public folder database, open CMD on your system and type the below command: Eseutil/mh “Path of the database.”
C:\program files\exchsrvr\bin>eseutil/mh “drive:\program files\exchsrvr\mdbdata\pub1.edb” - To check the private folder state of the database, type the below command:
C:\program files\exchsrvr\bin>eseutil/mh “drive:\program files\exchsrvr\mdbdata\priv1.edb”
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.
- Soft Recovery Method – With Log Files
If the log files are available, then troubleshooting dirty shutdown error using Eseutil utility is quite simple and straightforward. This solution is known as Soft Recovery of DB, in which the transaction logs are replayed with log and checkpoint files. The command that can be used to recover the database with log files uses a /R switch with Eseutil.
Eseutil /R E00 /L location of log files
E.g.,
Eseutil /R E00 /L c:\exchsrvr\logfiles
If the log files are missing, then the soft recovery method will fail. You can receive multiple errors when log files are missing or in Dirty Shutdown state. Some of the errors are:- Error – 501 (JET-err _errLogFileCorrupt) – “Log File is Corrupt”
- Error -515 (JET_errInvalidLogSequence) – “Any logfile from the sequence is missing”
- Error -514 (JET_errBadLogVersion) – “Log file generated with different Exchange Server or edition.”
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” - Repair – Without Log Files
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.
- Using Eseutil utility requires technical expertise because using it incorrectly can lead to data loss.
- It is necessary to have 110 percent the size of the database as free space.
- The Eseutil approach can take significant time depending upon the size of the database.
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.
Conclusion
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.
