Restore Inaccessible EDB Mailboxes From Dirty Shutdown State

What causes a database to going to a state of Dirty Shutdown? There are many reasons such as the database drive ended up with no disk space, antivirus is not Exchange Server aware, sudden power cut, hardware issues, damaged update or installation of third party applications, and the backup software is not Exchange Server aware.

If a database is in dirty shutdown state, this is most probably due to missing or corrupted logs. Why Exchange database log files are so important? If you think a log file is just a file holding events? Think again! Log files are more important than you think.

Role of Exchange Transaction Log Files

Exchange Transaction Log Files keep records of every transaction or changes performed or made on the database. These records in log files are then committed to the Exchange database file. If for some reason, the changes are not committed due to power failure, server crash, or log files went missing, the database may get dismounted or corrupt. Thus, log files play a critical role to keep the database healthy and optimized for performance. It also helps provide fast data access and protect the database from corruption or file locks.

However, if the database gets corrupt or does not mount, you can use third-party software, such as Stellar Repair for Exchange to fix the database file (EDB) corruption, extract mailboxes from the database and save them as importable PST format. You may also extract and import the mailboxes from the corrupt or dismounted databases to the Live Exchange server directly in a few clicks.

How do Log Files Work?

Server memory is the first thing that will be accessed when users connect to the Exchange server. This is where a transaction is stored.

事务存储in transaction logs and temporary on the server storage where these transactions are queued to be committed to the database. All transactions will remain in these log files before a backup of the database is complete.

During a backup process, transaction logs are committed to the database and logs are purged from the system. You cannot just delete a log file. In case you do it, you will be putting the consistency of the database at risk.

Another thing that you need to consider, so that you don't end up with a corrupted database or missing log files, is to have a backup software which is application-aware. If you fail to correctly backup your Exchange Server, you will end up with logs not being purged and it will fill all your storage eventually.

How Important are Transaction Logs when a Database is in Dirty Shutdown State?

When you have a database on Exchange Server which cannot be mounted, usually the culprit would be amissing or corrupted log file.A database can be in Dirty Shutdown or Clean Shutdown state. If a database is in Dirty Shutdown, you will not be able to mount the database.

If a database is dismounted with no issues, the transaction logs are committed to the database. After this process is complete, the database will successfully dismount. If a database is not dismounted correctly and when the server starts and sees that the database is still attached to uncommitted log files, it will stop the mount process and put the database in a Dirty Shutdown state.

When a modification or operation on the database is loaded into the cache memory but isn't committed to the database, it will be marked as Dirty Shutdown by the Jet Engine. This will remain until all the Dirty transactions are resolved and the database is considered as inconsistent. You will surely never want to shut down an Exchange Server abruptly without dismounting the databases smoothly.

What are the After-Effects of Dirty Shutdown and How to Tackle Them?

A dirty shutdown error is not easy to resolve. However, the native tools in Exchange help you identify the issues and guide you in restoring the database in a clean shutdown state.

You may encounter the following errors while mounting the database in Exchange and in the Application Events:

ERROR: database was not shutdown cleanly (dirty shutdown)
Operation terminated with error -550 (JET_errDatabaseDirtyShutdown, Database was not shutdown cleanly. Recovery must first be run to properly complete database
Unable to mount database. (hr=0x80004005, ec=-528)

To resolve this, you need to use the application calledEseUtil. By using this tool, with the /mh parameter, you will get a lot of information on the database. But most importantly, you will get to knowabout the state of the database and the missing or required log files.

How to Fix a Dirty Shutdown Error?

There are two methods to recover a database by using EseUtil:

Soft Recovery
Hard Recovery

NOTE: Recovering a database with EseUtil doesn't guarantee that the database will mount afterwards.

To start soft recovery, you need to run theEseUtil/rparameter including the required log file code from the /mh run, location of the log files and the database location (see the below example).

eseutil /r E03 /l M:\ExDb\logs /d M:\ExDb\DB01

Once this is complete, you can check the state of the database. If it is in clean shutdown, you can go ahead and mount the database. If this fails, you must run the hard recovery by using theeseutil/pparameter. If you run this, you must accept three things:

There is no 100% guarantee that the database will get mounted
You must accept data loss as it deletes any corrupted data
You cannot get Microsoft support after you run this

After the recovery is complete, you cannot just mount the database. You need to run a defragmentation process on the database to arrange the database data, compact and free the old data and unused pages. This can be done by using theNew-MailboxRepairRequestcmdlets. However, this process takes a considerate amount of time to complete, depending on the size of database.