A Complete Solution for Exchange Server Database Corruption and Dirty Shutdown

Introduction

When the exchange server starts up, it is being checked whether the database is being excluded from the transaction log.  So during this operation, it isn’t surprising for a normal database process to terminate abruptly. Transaction log files play a very vital role in effortless working of the exchange database. And, if the databases have some incompatibility in them, it results in the exchange to function unexpectedly or the start-up is at odds. Thus, an unexpected termination may lead to lose access to a backend storage, corrupting the file systems or server-wide power loss.

Details

Exchange transaction logs traces every changes that can be done in the database. The updating of data in user mailboxes is registered at the beginning in the log files and is then written to the databases. Once the size of the log files is full, then accordingly, a new one is created with the next sequence number.

Many Exchange support problems involve corrupt databases which will not mount.This restricts the users from accessing their mailbox data. The following pointers can prevent an exchange database from mounting:

• Inefficient start-up of the Microsoft Exchange Information Store Service
• Disappearance of Exchange database files.
• Database is in “Dirty Shutdown “State.
• Lack of free disk space or log files volume.
• Denial of access to underlying storage.
• While database is in clean or perfect shutdown state, significant logical corruption exists resulting in the dismountation of the database when the approach is done to read or access the data.

In situations where the Information Store Service fails to start, the most common or familiar issues include communications between Exchange and the anti-virus software. The event viewer is being recommended for verifying Active Directory communications as well as there is no service dependencies met. All exclusions have been properly configured by anti-virus software. Commonly, it can be discovered that an anti-virus product either locks the database or restricts the necessary RPC communications. Anti-virus is also a common reason for the corruption of database files as a result of a no. of processes attempted to access the files simultaneously. Commonly it is seen that an anti-virus product insulates database files or logs, a step that may break the sequence of the log stream, making recovery from backup challenging and possibly breaking DAG replication.

Dirty Shutdown

The words “Dirty Shutdown” are quite self-illustrative; either the database is down or in an unhealthy state. This can still cause trouble for Exchange Administrators who recall spending a lot of time while madly attempting to get a database to mount and restore functionality. Following through a lot of study over a hundred Dirty Shutdown Support cases it signifies that a lot of experience is not requires troubleshooting a Dirty Shutdown event accurately, since the perfect course of actions can easily fit or get into a decision tree. The below diagram shows a high level flow chart that shows the common scenarios where a database will not mount.

In a Dirty Shutdown, when exchange dismounts a database, the Information store ensures that all dirty database pages in cache are committed to the database (.edb) file. When  this allowance is done , the databases is stated to be in “ Clean Shutdown” state and needed no transaction logs to mount because all transactions have already been shown into the database. The below diagram shows the ESEUTIL utility ensures that a database is in Clean Shutdown state.

However, if something causes the database to terminate abnormally, it is expected to result in a Dirty Shutdown state.  Whether a Dirty Shutdown happens and the required transaction logs required for the recovery of the database is dependent fully upon the transactions which were being processed at the time of failure. Below diagram shows a database in Dirty Shutdown requiring log 3 (E0000000003.log) to mount.

It is noted that, there is an easy way to get a database into a Dirty Shutdown (for testing in lab purposes only) is to use Task Manager to kill the Store.exe (Exchange 2000-2010) or the Microsoft.Exchange.Store.Service.exe (Exchange 2013-2016)process. It is strictly recommended that before setting the Microsoft Exchange Service to be in the “Disable” state but not stopping it. This prevents the service itself to restart automatically and the attempt done to mount the database during inspection. The DB1 database which is being showed in the above diagram requires transaction log E0000000003.log because all the transactions which are contained inside this were either partially committed to the .edb file or are simply required to bring the database to a smooth state. Hardly, it is said that why certain logs are required without a deep programmatic understanding of JET Databases, but certainly the log is required and must be available before the database can be counted.

The other alternative is to leverage Stellar Phoenix Mailbox Exchange Recovery software.

Stellar Phoenix Mailbox Exchange Recovery accurately repairs corrupt Exchange Database (EDB) files and saves as MS Outlook PST file. It is capable of handling highly corrupt EDB files and restoring mailbox contents like emails, attachments, contacts, calendars, tasks, deleted items etc.

In Summation:

You are now aware of both the manual as well as the automated method of repair. While the manual methods call for precision and technical know-how, the automated method i.e. using Stellar Phoenix Mailbox Exchange Recovery software becomes a more viable option!

References:

https://www.stellarinfo.com/edb-exchange-server-recovery.htm
https://it.toolbox.com/blogs/recover-outlook/top-5-best-exchange-server-database-edb-recovery-software-for-it-administrators-76911