Technology

Submitted by: Submitted by

Views: 101

Words: 464

Pages: 2

Category: Science and Technology

Date Submitted: 08/06/2013 02:48 AM

Report This Essay

Ricky's Technology Blog

Skip to content

Home

About Me

Tips to Save Outlook OST Data when OST Fails to Synchronize with the Server →

Tips to Fix Exchange Dirty Shutdown State in Exchange Server

Posted on August 17, 2012 by rickytechblog

Microsoft has made some major enhancements in Exchange Server 2010 over its earlier versions. One of the most fundamental features is Data Availability Groups (DAGs). It enables you create a setup of multiple servers that host copies of individual databases. DAGs along with other features (such as Cluster Continuous Replication) ensure high availability of user mailboxes even in Exchange downtime situations. In addition, you can mix and match copies of databases stored on each server.

When an Exchange Server 2010 Mailbox Server is installed, a mailbox database is created automatically. This database contains the ‘.EDB’ file, ‘.CHK’ file, and ‘.LOG’ files. The actual data resides either in the server memory inside the log files or in the mailbox database. Initially, the mail data is stored in memory in the form of pages. These pages are updated as a part of transaction and then written to the log file. When the pages are not required by Exchange, they are written to the database. Lastly, changes are made to the checkpoint file to indicate the new checkpoint location.

Thus, the mailbox database file is an open file that has some of its data in the log files, before this is finally flushed to the database. At this stage, the database is dismounted and shut down cleanly. In case the Exchange Server crashes, the database will be shut down abnormally. This database state is known as the ‘dirty shutdown’ state. Here, the log files still contain the actual data. When you start the server again, it would perform an automatic recovery based on the data stored in the log files. The Exchange Server starts at the checkpoint and replays all the information after that to make your database consistent. If it fails to mount the database after...