Exchange 2013 Database in Dirty Shutdown State

You are here: Home / Exchange Server / Exchange Server Database Corruption and Dirty Shutdown Scenarios

This article is an excerpt from the Exchange Server Troubleshooting Companion.

During normal Exchange database operations, it's certainly not unusual for a database process to terminate unexpectedly. A termination might be due to losing access to backend storage, file system corruption, or server-wide power loss. Many Exchange support problems involve corrupt databases which will not mount, and therefore prevent users from accessing their mailbox data. The following issues can prevent an Exchange database from mounting:

• The Microsoft Exchange Information Store Service is unable to start
• Missing Exchange database files
• Database is in "Dirty Shutdown" state
• Not enough free disk space on database or log file volume
• Loss of access to underlying storage
• While database is in Clean Shutdown state, significant logical corruption exists causing the database to dismount when an attempt is made to read the data

In situations where the Information Store service will not start, the most common issues involve communications between Exchange and Active Directory or some interaction involving a file used by Exchange and anti-virus software. I recommend using event viewer to verify Active Directory communications as well as verifying there are no service dependencies not met (such as the Microsoft Exchange Active Directory Topology Service not being started). With anti-virus software, verify all exclusions have been properly configured. It is common to discover that an anti-virus product either locks the database files or blocks necessary RPC communications. Anti-virus is also a common reason why database files become corrupt as a result of multiple processes attempting to access the files simultaneously. It is also common to see that an anti-virus product quarantines database files or logs, a step that might break the sequence of the log stream, making recovery from backup challenging, and possibly breaking DAG replication.

Dirty Shutdown

The words "Dirty Shutdown" are fairly self-explanatory; a database is down and not in a healthy state. The words can still cause anxiety for Exchange Administrators who recall spending many hours while frantically attempting to get a database to mount and restore functionality. Over ten years of support, I have probably worked on well over a hundred Dirty Shutdown support cases. But to be honest, a decade worth of experience is not required to troubleshoot a Dirty Shutdown event accurately, especially since the proper course of actions can easily fit into a decision tree. The diagram below provides a high-level flow chart for navigating common scenarios where a database will not mount.

First, let's define what happens in a Dirty Shutdown. When Exchange dismounts a database, the Information Store ensures that all transactions (dirty database pages) in cache are committed to the database (.edb) file. When this is allowed to happen, the database is said to be in "Clean Shutdown" and requires no transaction logs to mount because all transactions have already been replayed into the database. The diagram below demonstrates how the ESEUTIL utility validates that a database is in Clean Shutdown state.

However, if something happens to cause the database to terminate abruptly, it is probable to result in a Dirty Shutdown state. Whether a Dirty Shutdown happens and which transaction logs may be required to recover the database is dependent entirely upon which transactions were being processed at the time of the failure. The diagram below displays a database in Dirty Shutdown, requiring log 3 (E0000000003.log) to mount.

Note: An easy way to get a database into Dirty Shutdown (for testing purposes, only do this in a lab) is to use Task Manager to kill the Store.exe (Exchange 2000-2010) or the Microsoft.Exchange.Store.Service.exe (Exchange 2013-2016) process. Before doing this, I recommend setting the Microsoft Exchange Information Store Service to "Disabled" (but not stopping it). This will prevent the service from automatically restarting itself and attempting to mount the database while you inspect it.

The DB1 database shown in the diagram above requires transaction log E0000000003.log because the transactions contained within it were either partially committed to the .edb file or are simply required to bring the database to a consistent state. It is hard to say exactly why certain logs are required without a deep programmatic understanding of JET Databases, but nonetheless the log is required and must be available before the database can be mounted.

Learn more about solving Exchange database problems in the Exchange Server Troubleshooting Companion.

Exchange 2013 Database in Dirty Shutdown State

Source: https://practical365.com/exchange-server-database-corruption-and-dirty-shutdown-scenarios/

Share this post