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.
Exchange Server uses Server Memory, log files and the database. These three objects are used to offer Exchange services to the users. This is done to keep the database healthy and optimize performance. The other reason is to provide fast data access and protect the database from corruption or file locks.
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.
When you have a database on Exchange Server which cannot be mounted, usually the culprit would be a missing 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.
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:
To resolve this, you need to use the application called EseUtil. 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.
There are two methods to recover a database by using EseUtil:
NOTE: Recovering a database with EseUtil doesn't guarantee that the database will mount afterwards.
To start soft recovery, you need to run the EseUtil/r parameter 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 the eseutil/p parameter. If you run this, you must accept three things:
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 the New-MailboxRepairRequest cmdlets. However, this process takes a considerate amount of time to complete, depending on the size of database.
By using the native tools to repair a database, you will end up investing your several precious hours.On the other hand, the users will not be able to access, send or receive emails during the process. Apart from the business aspects, where business opportunities can be lost due to the downtime, loss of data can result in legal obligations. The solution would be to have the issue rectified in the least possible time and without data loss.
You can use Stellar Repair for Exchange software that can repair damaged databases and extract mailboxes in common formats such as PST, EML and PDF. In case the database is down, you can create a new blank database so that the users can work by sending and receiving emails. So, the users will gradually see the old emails coming up into their mailboxes with minimum risk and interruption to their business and daily work. The application can also be used for Office 365 migrations as it can export an EDB file directly to an Office 365 tenant. Stellar Repair for Exchange is compatible with all Exchange database formats from 5.5 to the latest 2019 version.
This article explains to get back all their old mail and restore the original mail from crashed Exchange server. Explore all technical know-how or the right tools in hand to have a quick recovery with minimal downtime, for the Exchange Admins.
Experts recommend to use Eseutil/mh command to identify Exchange database state. If your database in ‘Dirty Shutdown State’ then use eseutil/mh commands to change the database state to ‘Clean Shutdown’.
Run ESEUTIL /P commands to complete Exchange database hard repair process using . ESEUTIL /P – repair corrupt or damaged exchange database EDB files smoothly.
how you can repair a PST file after a changes with MDBVU32. This free method also supports Windows 10 and Outlook 2016.
Useful tips to fix file File Level Exchange Server Database Error 1018, 1019 and 1022. It is applicable for all Exchange Server versions 2016 / 2013.