Determine Database State Using ESEutil /MH Command

Database state can be determine using eseutil/mh command to examine whether the database is in dirty Shutdown state and clean shutdown state.


Dirty Shutdown State: If the Exchange server database isn't shutdown correctly, then it's found that the database remains "attached" with the transaction log stream. This is known as dirty shutdown state.


Clean Shutdown State: If the Exchange server database has been shutdown correctly, the database gets completely "detach" to its transaction log stream. This is known as clean shutdown state.


Easily determine the state of database


User can easily identify that whether a database is "detach" or "attach" by checking the DB file header with the help of ESEutil utility's /MH command switch.


  • eseutil /mh syntax: eseutil/MH database-name.

Note: To examine database header using eseutil, database must be stopped.

After running the above mention command, the state value appears on the screen giving details about whether the database is correctly detach or attach.

  1. If the database has been correctly detached, the state value will be either Clean Shutdown or Consistent state, depending upon the current running version of Exchange server.

  2. If the database isn't correctly detached, this means that the database is either in Dirty Shutdown or Inconsistent state.

A Brief of Exchange Server Database

Exchange server database transaction log files keeps records of all changes of an Exchange server database. These log files has fixed size, thus when the log is space is full a new current log file will be created by renaming transactional log file with a new numeric sequence number. Over time, these logs files use up all free disk space which sometimes enables user to access data any further. Thus to resolve this issue user can manually remove the transactional log files. But only under some considerations like user need to determine that the database is safe to remove. Unfortunately, if the user accidently removed the log details which aren't yet been added in the database file. Then they are not able to mount data after an abnormal stop. Thus it is required to determine which logs are safe to remove, determine the state value of the logs before removing the data manually.


Although you can manually remove transactional log files but before doing so user must need to recognize the current state of database that uses the particular transactional log files. For this user needs to find out the "attach" and "detach" state of databases that was used by the transactional log files.

This was the complete details about database states and how to check the existing state of database.