Exchange Server is an email-based communication server
used in conjunction with MS Outlook by most organizations to maintain smooth
and efficient business communication. Exchange also offers great ease and
flexibility to the users to access their mailbox information either using
Outlook or Outlook Web Access, suiting as per their needs and conveniences.
In order to save the user mailbox information, MS
Exchange information store relies upon Exchange database files (EDB) and keep
them as a backup repository in case the user accidently deletes the emails or
mailbox content.
Unfortunately, EDB files of Information Store is
vulnerable to corruption as well, like any other database files. Exchange dirty
shutdown is one such corruption error that you may encounter due to an abrupt
termination of Information Store.
In such a scenario, the user is displayed an error
message indicating:
Exchange Server database is designed on JET engines, in
which log files are given a significant role to keep a constant record of input
and output operations going in the EDB files. But when these log files are left
in the cached memory without being committed to the Information Store, then JET
engine term them as DIRTY. And in this incomplete process, if the system is
turn off accidentally, it displays dirty shutdown error.
Reason for Dirty Shutdown State
The main reason for dirty shutdown is caused due to the
inconsistency in transactions of the transactional log files. The database goes
in the dirty shutdown state when EDB or STM files are not properly detached
from the transaction log files. Because of this issue, the server is unable to
read the transaction logs and hence create transactional discrepancy. And in
this situation, when the user tries to open the EDB files, it displays the
dirty shutdown error.
Note: A transaction log file is a highly
important piece of information for database as it consistently keeps a track of
all changes made in the exchange database. And the changes made on those user
mailboxes are first registered in these log files and then to the database. The
log files are generated in sequence and helping users to understand the
complete log history.
Verify a clean or dirty shutdown state
You may verify whether the database is properly detached
from transaction files or not, in order to check it is a clean or dirty
shutdown state. To analyze the state of database, follow the below provided
steps:
Go to the ‘Start’ button and then type ‘cmd’
in the run textbox and hit enter.
Note: here it is assumed that your Exchange
Server is installed at this location ‘c:\program files\exchsrvr folder’ and
the database is saved is this path: ‘c:\program files\exchsrvr\mdbdata
folder’
Now, type the given command, for private folder:
Now, type the given command, for private folder:
Type the given command, for public folder:
Verify the exchange database state, as:
In the clean shutdown state, your database is detached
properly
In the dirty shutdown state, the transactions are not
committed to the database
RESOLUTION:
In order to resolve the issue of dirty shutdown error, it
is required to bring the database back into a clean shutdown state. For this,
transactional log files have to be replayed in the database. Follow the below
mentioned steps to achieve clean shutdown state using manual technique:
Keep a backup of entire exchange database files,
including log files, private & public folder files and STM files to a
secure location on the system. Also, make sure you have sufficient space in
your system to perform repairing process.
Use Eseutil, an inbuilt repair utility of Exchange Server
to check the consistency of the database.
Run the following command on the tool:
eseutil/mh “C:\ program files\
exchsrvr\ mdbdata\ priv1.edb”
If the database is affected from dirty shutdown state,
then run the following command to perform soft repair on corrupt EDB files:
eseutil/r “C:\ program files\ exchsrvr\
mdbdata\ priv1.edb“
Again, check for database consistency. If it is still
found in an inconsistent state, then use the following command to perform hard
repair on corrupt EDB files:
eseutil/p “C:\ program files\ exchsrvr\
mdbdata\ priv1.edb“
Defrag the database store by running this command “Eseutil/d” on
the utility.
Lastly, check the integrity of the database by using
another utility “Isinteg”. Now run this command line :
“Isinteg –s servername –fix –test alltests“
However, if you do not achieve the desired results using
the manual technique or find the aforementioned technique an arduous task, then
try using a reliable third-party Exchange Server recovery tool. Kernel for Exchange Server is a
result-oriented yet friendly-working tool to repair corrupt EDB and STM files
within a matter of minutes.
In three simple steps, users can successfully bring the
database to error-free clean shutdown state. Other than dirty shutdown error,
this tool can solely repair EDB files from all corruption conditions and
capable enough to restore the recovered files to various platforms like
Outlook, Office365, email server or web mails in a single attempt.
No comments:
Post a Comment