Exchange 2003, 2007 and 2010 Database Dirty Shutdown

While normal MS Exchange databases operations, database processes are likely to terminate unpredictably. This unexpected Exchange Database Dirty Shutdown can happen because of access-loss to back-end storage or due to some corruption in the file-system, or due to server-wide loss of power. Many of the MS Exchange support issues entail damaged databases that don’t mount, and so preventing user-access to mailbox’s data. In the below points we are going to explain various reasons for such Dirty Shutdown of Exchange Database shutdowns & its prevention.

Causes Why Any Exchange Database Doesn’t Mount

The issues that prevent mounting of any Exchange Database Dirty Shutdown are as follows:
1.MS Exchange’s Information-Store-Service somehow not initialise.
2.Missing MS Exchange’s database files.
3.Exchange’s Database in the state of sudden shutdown.
4.Not sufficient disk space that is free on the database.
5.Insufficient disk space that is free on the log file volume.
6.Loss of underlying storage’s access…
7.Check Exchange Database For Dirty Shutdown.
8.Unable to mount Database Exchange 2010 clean shutdown.

A Database is in its Clean-Shutdown state and some logical corruption happens leading to the dismounting of that Exchange 2003, 2007 and 2010 Database while attempts are being made to read the data within it. Now, we going to brief about how to check Exchange Database For Dirty Shutdown & Repair Dirty Shutdown Exchange.

About Exchange Database Dirty Shutdown

The term, Exchange Dirty Shutdown is kind of self-explanatory. It refers to a Database when it is down and when that database is somehow not in a healthy state. Exchange admins remain anxious while spending hours and hours to check Exchange Database by Exchange Database Repair command For Dirty Shutdown in getting their databases to mount & finally restore their functionalities.

What Happens during Dirty Shutdown?

When a Database status is Dirty Shutdown MS Exchange 2007 & MS Exchange database somehow dismounts or stop responding. Although, its Information-Store is there for ensuring all transactions (basically the dirty-database pages) that are in the cache have been committed to database’s EDB file. When such a thing has been allowed for happening, then that database is said to be in the state of “Clean Shutdown” and needs no such transaction logs for mounting as all transactions already replay into that database. But, when something causes Database to unexpectedly terminate, then results it in this Exchange Database Dirty Shutdown state. Now the probability of Dirty Shutdown happening and what are transaction logs would be needed for recovering that database entirely depends on what all transactions were processed during the time of database failure.

Some Key Questions

1. When was the latest useful backup taken?
a. This is needed as users may have to restore data from that backup and after that attempt towards replaying the log files. A backup file is necessary to build so as to get the previous data simultaneously & To Bring Exchange Database clean shutdown.
2. Was that database in its own storage group or in some storage group that is shared by other databases?
a. If that Exchange Database Dirty Shutdown was in the shared SG with other databases that were online, then those may be needed to be taken offline while recovery. So just to be safe, users must move those mailboxes out from that SG before they dismount the “healthy” databases, if that is possible to do otherwise user Exchange Database Clean Shutdown won’t mount.
3. Do the LOG files still exist or they got lost?
a. If the LOG files still exist, then users would be able to replay them for bringing database up-to-date with ESEUTIL /R. However, if the LOG file does not exist any longer, then recovery options would be very limited. Also, if LOG files have unfortunately got corrupted i.e. Logical Corruption Exchange Database, then users can use the /ML switch for testing for those corrupted LOG files.

Steps to Perform Exchange Database Recovery Manually

If user is having the LOG ESEUTIL /R, then it may get back things up and in running mode by with only slim chances of loss of any data. Following are the steps of the manual method for recovery:

1. Run ESEUTIL /mh (dump headers)
a. This helps in checking the database status, and that must shows up the Exchange Database Dirty Shutdown.
2. Run ESEUTIL /R /D
a. If more than one databases were there inside the storage group, then user would need to add the /i option. This is when Exchange Database is in Dirty Shutdown
3. Run ESEUTIL /mh (dump headers)
a. This helps in checking the database status; it must bring Exchange Database Clean Shutdown.

Another Easier Alternative

If the manual method does not seem like the right solution for Exchange Database Dirty Shutdown, then you can always turn to professional services. One such well-known vendor in this domain is SysTools Software Group.

Conclusion

The blog explained Exchange Database is in a Dirty Shutdown state. After performing the manual method steps as described above, if the database state still shows the Exchange Database Clean Shutdown Won’t Mount state, then you would need to Exchange 2007 Database Dirty Shutdown Repair. For that, third-party tools can serve the purpose well. Exchange Database Dirty Shutdown.