When Exchange Server starts up, it checks out if the database is being detached from the transaction log, i.e. it ensures that there are no pending transactions to be written to the database. In case the database is attached to the transaction log, Exchange Server detaches it by replaying the available log files.
The log files are a great asset in situations when older version of database has to be restored. This is the reason it is strictly recommended not to delete any log file permanently. Consistency of an ESE database completely depends upon committed transaction that is marked with atomicity and durability features of ACID technique.
Follow the steps below to test if the DB is in clean shutdown state or dirty shutdown state »
Open Command Prompt and type this command for public folder state check –
Example :
Now, to check private folder state, enter the command –
If state of DB is Clean Shutdown, it means the database is detached from transaction and is consistent.
If state of DB is Dirty Shutdown, it means the database is still attached to transaction and is inconsistent.
What does Dirty System Shutdown Means? Exchange Server database is based JET Blue engine technology that is named as Exchange Storage Engine. This ESE uses database cache in order to minimize the number of Input-Output operations to the transaction logs.
Until the updation to the database is not written into it (outstanding transaction), the JET engine marks the DB pages as DIRTY. Since an interruption caused the system to shutdown, preventing transaction to commit to the database, state of DB is marked as Dirty System Shutdown.
Error 550:
Error 528:
In this scenario, the solution is Soft Recovery of DB where the transaction logs will be replayed using log and checkpoint files. For this, use Eseutil which is a command line utility to perform various operations against database using variety of switches.
Before moving on to soft recovery, it is important to test the state of the log files. For this, use /ml switch of Eseutil. The syntax is: Eseutil /ml "Path of the log files\log prefix
Syntax for Soft Recovery:
In this case, hard recovery of database will work out. This type of recovery differs from the one mentioned above as it replays transaction log by restoring DB from online backup. If recent and valid database backup is available, then restore .edb, .stm, and .log files from them. Once this process is done, restore.env file will get created in temporary folders.
Note: Ensure that a copy of restore.env and log files is created as hard recovery process involves loss of some data.
Syntax for Hard Recovery:
After hard repair is complete, the temporary folder with restore.env file will be empty.
In case the log files are inconsistent and there is no backup, then the suggestion is to repair the database using /p switch.
Syntax for Database Repair:
A message will be prompted stating that the process might result in data loss. Do you want to proceed? Click OK.
The DB repair process will get started (unused pages from the DB will be removed in this process).
Now, once the recovery process is finished, test the state of database using /mh switch again. If the state is Clean Shutdown, then move to offline defragmentation process.
The purpose of defragmenting the recovered database is to remove unused pages from it where resultant is a new DB free from unused pages. Syntax for defragmentation is eseutil /d Database_Name.
Things to Remember: Before using Eseutil to fix Dirty Shutdown state of database, following points should be considered:
If Eseutil is not your choice, then opt for Exchange Server Recovery software that extracts mailboxes from database .edb file (in dirty shutdown state) and migrates it to desired Server. The tool is a simplified alternative to Eseutil and helps in recovering mailboxes from Exchange Server database.
