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.
- Server memory is the first thing that will be accessed when users connect to the Exchange server. This is where a transaction is stored.
The 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 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.
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 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.
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 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:
- 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 the New-MailboxRepairRequest cmdlets. However, this process takes a considerate amount of time to complete, depending on the size of database.
Video Tutorial to fix a dirty shutdown error
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.