During regular Exchange database operations, an unexpected termination of the database process is not very surprising. It is one of the common scenarios that may occur anytime.<\/p>\n
Most of the Exchange server problems arise due to corrupt databases which don\u2019t get mounted, and thus, prevents users from accessing their mailbox data. There are many issues which prevent the mounting of an Exchange database, and one of these issues is the \u201cDirty Shutdown\u201d issue when it happens, the database administrators (DBAs) are required to handle Dirty Shutdown in Exchange Server 2016 or whichever variant of Exchange Server is installed to make sure that the database gets mounted.<\/p>\n
What exactly is \u201cDirty Shutdown\u201d?<\/b><\/p>\n
The term \u201cDirty Shutdown\u201d implies that the database is down and is not in a healthy state. When this happens, the DBAs are required to follow a proper course of action in order to fix the Dirty Shutdown in Exchange Server 2010, 2016, 2013 or 2007. Once the issue is fixed, the database can be restored and made accessible to users.<\/p>\n
How To Repair The Exchange Server Database After A Dirty Shutdown?<\/b><\/p>\n
Follow the below-given steps to fix the issue and recover your database on the Exchange Server efficiently after a Dirty shut down without any data loss. The following methodology can be applied to both the latest version of the Exchange server as well as the older versions \u2014<\/p>\n
1.\u00a0\u00a0\u00a0<\/b>Back up The Files<\/b><\/p>\n
First of all, back up all the edb, stm files, as well the logs. To do this, copy the pub.edb, priv.edb, all the stm files and logs to a secure location like the disk.<\/p>\n
2.\u00a0\u00a0<\/b>Free Up the Disk Space<\/b><\/p>\n
In order\u00a0 to recover the database from a Dirty Shutdown state, you need to ensure that there is 110% of empty disk space. Don\u2019t use the shared space and make sure to keep a continuous space for recovery, which is 110% of the size of the database.<\/p>\n
3.\u00a0<\/b>Check for Database Consistency<\/b><\/p>\n
In order to check the consistency of the Database, run the following command:<\/p>\n
[eseutil \/mh \u201cpath of priv<\/i>.edb\u201d]<\/p>\n
So, if you have stored your priv.edb file in the C partition and database folder, then you can write this command in the following manner:<\/p>\n
(eseutil \/mh \u201cc:\\database\\mailbox database.edb\u201d)<\/p>\n
4.\u00a0\u00a0<\/b>Check The Database Status<\/b><\/p>\n
The status of the database must indicate \u2013 \u201cDirty Shutdown\u201d<\/p>\n
Once you encounter that the status is showing \u201cDirty Shutdown\u201d, you can first try the \u201cSoft Repair\u201d and if that does not work, then try using \u201cHard Repair\u201d. Let\u2019s look into each method:<\/p>\n
i.\u00a0\u00a0<\/b>Run Soft Repair<\/b><\/p>\n
The following command that initiates the soft repair is [eseutil \/r]; however, it must be run from the database log folder only.<\/p>\n
[eseutil \/r “prefix<\/i>“<E00> \/l <log file location<\/i>> \/d <location of database<\/i>>]<\/p>\n
If both the log file and database are located in the C partition, then you can run the aforementioned command as:<\/p>\n
Eseutil \/r E00 \/l c:\\dblog \/d c:\\db<\/p>\n
Check The DB Consistency<\/b><\/p>\n
Check the database consistency again and if it shows a clear shutdown, directly go to Step 6. But, if soft repair didn\u2019t work, then run the hard repair.<\/p>\n
ii.\u00a0\u00a0<\/b>Hard Repair<\/b><\/p>\n
Following is the command for running the hard repair<\/p>\n
(Eseutil \/p \u201clocation of mailbox database.edb\u201d)<\/p>\n
If the mailbox database is located in the C partition, under the \u201cProgram Files\u201d folder in the relevant folder and files, then run the following command:<\/p>\n
Eseutil \/p “c:\\program files\\exchangesrvr\\maildbdata\\priv1.edb”<\/p>\n
5.\u00a0<\/b>Defragment the DB<\/b><\/p>\n
Now defragment the DB using the eseutil \/d command applied to the mailbox database file. Run the command with the following syntax:<\/p>\n
Eseutil \/d “c:\\program files\\exchsrvr\\mdbdata\\priv1.edb”<\/p>\n
After executing this command, remove the log files in the MDBDATA folder before commencing with the database mounting.<\/p>\n
6.\u00a0\u00a0<\/b>Check DB Integrity<\/b><\/p>\n
This command takes up to 10 minutes per Gig of Data; therefore, if you don\u2019t have enough time, this step can be skipped after a soft recovery procedure.<\/p>\n
But, if you have attempted hard recovery, then you must run it. Try checking the integer of the database with the following command:<\/p>\n
[isinteg -s “name of the server” -test alltests]<\/i><\/p>\n
If this integer check fails, then run the following command<\/p>\n
[isinteg -s “servername” \u2013fix \u2013test – alltests]<\/i><\/p>\n
Run this command repeatedly till all the errors reach the level 0, or the status starts showing no changes.<\/p>\n
7.\u00a0\u00a0<\/b>Check the DB Consistency<\/b><\/p>\n
Now check the DB consistency, with the following command<\/p>\n
Eseutil \/mh and it must show \u201cclear shutdown\u201d as the status.<\/p>\n
With the aforementioned steps, one can easily recover the database <\/b>repair exchange database file.<\/p>\n","protected":false},"excerpt":{"rendered":"
During regular Exchange database operations, an unexpected termination of the database process is not very surprising. It is one of the common scenarios that may occur anytime. Most of the Exchange server problems arise due to corrupt databases which don\u2019t get mounted, and thus, prevents users from accessing their mailbox data. There are many issues […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-440","post","type-post","status-publish","format-standard","hentry","category-exchange-server"],"yoast_head":"\n