Understanding the Exchange 2010 Store

Exchange 2010
Other Versions

Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2

Topic Last Modified: 2013-10-25

The Exchange store is a storage platform that provides a single repository for
managing multiple types of information in one infrastructure. The Exchange store
(store.exe) is the core data storage repository for Microsoft Exchange Server 2010.

Contents

Databases in Editions of Exchange 2010

Logical Components of the Exchange Store

File Structure of the Exchange Store

Understanding Transaction Logging

Extensible Storage Engine

Store Health

Low Disk Space on Database Logs or Database Drives

Exchange Store Limits

Databases in Editions of Exchange 2010
Exchange 2010 is available in two server editions: Standard Edition and Enterprise
Edition. Exchange 2010 Standard Edition is designed to meet the messaging and
collaboration needs of small and medium corporations, and it may also be
appropriate for specific server roles or branch offices. Exchange 2010 Enterprise
Edition is designed for large enterprises.

Exchange 2010 Standard Edition supports up to five databases. Exchange 2010

Enterprise Edition supports up to 100 databases.
Logical Components of the Exchange Store

The primary components of the Exchange store are mailbox databases and public
folder databases. These components can reside on a single server, or they can be
distributed across multiple servers.

Mailbox databases contain the data, data definitions, indexes, checksums, flags,
and other information that comprise mailboxes in Exchange 2010. Mailbox
databases hold data that's private to an individual user and contain mailbox folders
generated when a mailbox is created for that user. A mailbox database is stored as
an Exchange database (.edb) file.

Public folder databases contain the data, data definitions, indexes, checksums,
flags, and other information that comprise any public folders in your Exchange
organization.

In Exchange 2010, you manage public folders by using the Exchange Management
Shell. (You can also perform a limited number of public folder database
management tasks in the Exchange Management Console.) For more information
about managing public folders, see Managing Public Folders and Understanding
Public Folders.

Return to top
File Structure of the Exchange Store

You manage the Exchange store by working with its logical components, such as
databases. However, Exchange 2010 stores data in a specialized set of data files,
such as Exchange database (.edb) files, transaction log (.log) files, and checkpoint
(.chk) files. Unless you're backing up or restoring data, you rarely interact with
these files directly. The following table describes each of these files in more detail.
File structure of Exchange store
Data file Description

Exchange database (.edb)

These files are the repository for mailbox data. They're accessed by the Extensible
Storage Engine (ESE) directly and have a B-tree structure designed for quick access.
This enables users to access any page of data within one input/output (I/O) cycle,
which is a four-fold increase compared to Microsoft Exchange Server 2007.
Exchange databases are composed of multiple B-trees, with ancillary trees that
work with the main tree by holding indexing and views.

Transaction log (.log)

These files are the repository for database operations such as creating or modifying
a message. Committed operations are later written to the database itself (in an .edb
file). This approach guarantees that all complete and incomplete transactions are
logged to maintain data integrity in case of a service interruption. Each database
has its own set of transaction logs.

Checkpoint (.chk)

These files are the repository for data that indicates when an operation is
successfully saved to the database on the hard disk. Exchange 2010 uses .chk files
so an instance of the ESE can automatically replay log files into an inconsistent
database when recovering from a service interruption, starting with the next
unwritten operation. The .chk files are placed in the same log location as the .log
files.

Return to top
Understanding Transaction Logging

Exchange transaction logging is a robust recovery mechanism of the ESE designed

to reliably restore an Exchange database to a consistent state after any sudden stop
of the database. The logging mechanism is also used when restoring online
backups. This section describes the details of Exchange 2010 transaction logging
and includes a brief description of circular logging.
Exchange Transaction Logging

Before changes are made to an Exchange database file, Exchange writes the
changes to a transaction log file. After a change is safely logged, it can then be
written to the database file. It's common for these changes to become available to
end users just after the changes are secured to the transaction log, but before the
changes are written to the database file.

Exchange employs a sophisticated internal memory management system tuned for

high performance, which efficiently manages the caching of dozens of gigabytes
(GB) of database pages. Physically writing changes to the database file is a low-
priority task during normal operation.

If a database suddenly stops, cached changes aren't lost just because the memory
cache was destroyed. When the database restarts, Exchange scans the log files, and
reconstructs and applies any changes not yet written to the database file. This
process is called replaying log files. The database is structured so that Exchange
can determine whether any operation in any log file has already been applied to the
database, needs to be applied to the database, or doesn't belong to the database.

Rather than write all log information to a single large file, Exchange uses a series of
log files, each exactly one megabyte (MB), or 1,024 kilobytes (KB), in size. When a
log file is full, Exchange closes it and renames it with a sequential number. The first
log filled ends with the name Enn00000001.log. The nn refers to a two-digit number
known as the base name or log prefix.

Log files for each database are distinguished by file names with numbered prefixes
(for example, E00, E01, E02, or E03). The log file currently open for a database is
named Enn.log. It doesn't have a sequence number until it has been filled and
closed.
The checkpoint file (Enn.chk) tracks how far Exchange has progressed in writing
logged information to the database files. There's a checkpoint file for each log
stream, and a separate log stream for each database.

Log files are numbered in a hexadecimal manner, so the log file after
E0000000009.log is E000000000A.log, and not E0000000010.log. You can convert
log file sequence numbers to their decimal values by using the Windows Calculator
(Calc.exe) application in Scientific mode. To do this, run Calc.exe, and then from the
View menu, click Scientific.

To view the decimal sequence number for a specific log file, you can examine its
header by using the Exchange Server Database Utilities (Eseutil.exe) tool. The first
4-KB page of each log file contains header information that describes and identifies
the log file and the databases it belongs to. The command Eseutil /ml [log file name]
displays the header information.

If you use the wrong switch for displaying a header (for example, by using /ml with a
database header instead of /mh), an error is displayed or the header information
displayed may be garbled or incorrect.

You can't view the header of a database while it's mounted. You also can't view the
header of the current log file (Enn.log) while any database is mounted. Exchange
holds the current log file open as long as one database is using it. However, you can
view the checkpoint file header while databases are mounted. Exchange updates
the checkpoint file every thirty seconds, and its header is viewable except during
the moment when an update is occurring.

As an Exchange administrator, it's valuable to understand Exchange file headers. If

you understand file headers, you can determine which database and log files belong
together and which files are needed for successful recovery.

In the following log file header example, note the first four lines.

Base name: e00

Log file: e00.log
lGeneration: 11 (0xB)
Checkpoint: (0xB,7DC,6F)
These log file header lines show that this log file is the current log file because the
log file name doesn't have a sequence number. The lGeneration line shows that
when the log is filled and closed, its sequence number is B, corresponding to the
decimal value 11. The base name is e00, and therefore the final log file name will be
E000000000B.log.

The Checkpoint value in the previous header example isn't actually read from the
log file header, but it's displayed as if it were. Eseutil.exe reads the Checkpoint
value directly from Enn.chk, so you don't have to enter a separate command to
learn where the checkpoint file is. If the checkpoint file has been destroyed, the
Checkpoint value reads NOT AVAILABLE. In this case, the checkpoint is in the current
log file (0xB), and the numbers 7DC and 6F indicate how far into the log file the
checkpoint is. Note that you seldom have a practical need for this information.

If the checkpoint file is destroyed, Exchange can still recover and replay log files
appropriately. But to do so, Exchange begins scanning log files, beginning with the
oldest file available, instead of starting at the checkpoint log. Exchange skips data
that has already been applied to the database and works sequentially through the
logs until data that must be applied is encountered.

Typically, it takes only one or two seconds for Exchange to scan a log file that has
already been applied to the database. If there are operations in a log file that must
be written to the database, it can take anywhere from 10 seconds to several
minutes to apply them. On average, a log file's contents can be written to the
database in 30 seconds or less.

When an Exchange database shuts down normally, all outstanding data is written to
the database files. After normal shutdown, the database file set is considered
consistent, and Exchange detaches it from its log stream. This means that the
database files are now self-contained (up to date). The transaction logs aren't
required to start the database files.

You can tell whether a database has been shut down cleanly by running the
command Eseutil /mh and examining the file headers.

With all databases disconnected and in a Clean Shutdown state, all log files can be
safely deleted without affecting the databases. If you were then to delete all log
files, Exchange would generate a new sequence of logs starting with
Enn00000001.log. You could move the database files to a different server that has
existing log files, and the databases would attach themselves to a different log
stream.
noteNote:
Although you can delete the log files after all databases have been shut down,
doing so affects your ability to restore older backups and roll forward. The current
database no longer needs the existing log files, but they may be necessary if you
must restore an older database.

If a database is in a Dirty Shutdown state, all existing transaction logs from the
checkpoint forward must be present before you can mount the database again. If
these logs are unavailable, you must repair the database by running the command
Eseutil /p to make the database consistent and ready to start.
CautionCaution:
If you have to repair a database, some data will be lost. Data loss is frequently
minimal; however, it may be catastrophic. After running Eseutil /p on a database,
you should run Eseutil/ d to defragment the database. This operation discards and
rebuilds all database indexes and space trees.

In addition to allowing Exchange to recover reliably from an unexpected database

stop, transaction logging is also essential to making and restoring online backups.
For more information about making and restoring online backups, see
Understanding Backup, Restore and Disaster Recovery.

Return to top
Circular Logging

You can configure Exchange to save disk space by enabling circular logging. Circular
logging allows Exchange to overwrite transaction log files after the data that the log
files contain is committed to the database. However, if circular logging is enabled,
you can recover data only up until the last full backup. For example, you can enable
circular logging when using Exchange native data protection, in which you don't
make backups. To prevent log buildup, you need to enable circular logging.

In the standard transaction logging used by Exchange 2010, each database

transaction is written to a log file and then to the database. When a log file reaches
one MB in size, it's renamed, and a new log file is created. Over time, this results in
a set of log files. If Exchange stops unexpectedly, you can recover the transactions
by replaying the data from these log files into the database. Circular logging
overwrites and reuses the first log file after the data it contains has been written to
the database.

In Exchange 2010, circular logging is disabled by default. By enabling it, you reduce
drive storage space requirements. However, without a complete set of transaction
log files, you can't recover any data more recent than the last full backup. In a
normal production environment, circular logging isn't recommended.

For information about how to enable and disable circular logging, see Configure
Mailbox Database Properties.

Return to top
Extensible Storage Engine

Exchange mailbox databases and the queue on Hub Transport servers and Edge
Transport servers utilize the ESE database. ESE is a multiuser, indexed sequential
access method (ISAM) table manager with full data manipulation language (DML)
and data definition language (DDL) capability. ESE allows applications to store
records and create indexes to access those records in different ways. For more
information about ESE, see Extensible Storage Engine Architecture. For
improvements in Exchange 2010 ESE, see New Exchange Core Store Functionality.

Return to top
Store Health

The Exchange store can detect and correct several scenarios that can cause the
store to become unhealthy. The Exchange store can handle poison mailboxes and
thread time-outs, use report and alert features to signal an unhealthy Exchange
store state, and detect and repair mailbox database and public folder database
issues.
Poison Mailbox Detection and Correction

A single mailbox with corrupted data (logical or physical) may in some cases cause
the Exchange store to fail, and deny service to all mailboxes hosted by the server.
Similarly, a poison mailbox could also cause the Exchange store to repeatedly fail.
This section describes the actions the Exchange store takes to detect and cut off
poison mailboxes.
Isolating the Poison Mailbox

There are several types of events for which the Exchange store tags a mailbox as a
potential threat:

If a thread doing work for that mailbox fails

If there are more than five threads in that mailbox that haven't made progress for
a long time

A mailbox that's a potential threat is tagged, along with a count of how many times
it has been tagged. This information is stored in the registry. The Exchange store
also keeps timestamp information about when the mailbox was identified as a
potential threat.

During a database mount, the Exchange store reads the time that the mailboxes
were identified as potential threats. If more than two hours has elapsed, the registry
key for the mailbox is deleted. The advantage of keeping this information in the
registry is that in a high availability environment, it's replicated by the cluster
database. Even during an Exchange store failover, the other computers have this
information. The registry subkey thats used to isolate the poison mailbox is
HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<Server Name>\Private-
{db guid}\QuarantinedMailboxes\{mailbox guid}. The keys for this path are
CrashCount and LastCrashTime.

The settings for the amount of failures that lead to quarantining a mailbox and also
for the amount of time that a mailbox should stay quarantined are stored in the
MailboxQuarantineCrashThreshold and MailboxQuarantineDurationInSeconds keys in
the HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<Server
Name>\Private-{db guid} subkey.

The default values for these keys are three failures for
MailboxQuarantineCrashThreshold and 21,600 seconds (six hours) for
MailboxQuarantineDurationInSeconds.
Acting on the Poison Mailbox
By default, if a mailbox is identified as causing a failure or deadlock three times
within two hours, the Exchange store tags it as quarantined in the registry. No
access is allowed to the mailbox unless the OPEN_AS_ADMIN flag is passed. None of
the Exchange processes (for example, content indexing or the Mailbox assistants)
are allowed to log on. The QuarantineState and QuarantineTime registry keys keep
track of whether the mailbox is quarantined. If the mailbox hasn't caused any
failures in the last two hours and isn't quarantined, the registry path for the mailbox
is cleaned up by the Exchange store. If a mailbox has been quarantined for longer
than the MailboxQuarantineDurationInSeconds value since its LastCrashTime value,
it's released from quarantine automatically.
Resetting the Quarantined Mailbox

When the cause of the poison mailbox has been identified and corrected, the
registry key for the quarantined mailbox should be reset manually by deleting it.
However, if this manual step is forgotten, the Exchange store automatically resets
quarantined mailboxes six hours after the quarantined flag was set. If the issue isn't
debugged and fixed within that time period, this may lead to another set of failures
before the mailbox or message is quarantined again.
noteNote:
The database hosting the mailbox needs to be remounted, or the Exchange store
restarted, for the reset of the quarantined mailbox to take effect.

The time period for resetting quarantined mailboxes can be controlled by the
registry key HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<Server
Name>\Private-{db guid}\MailboxQuarantineDurationInSeconds.
Reporting and Alerts

You can use the Get-MailboxStatistics cmdlet to report the quarantined state of a
mailbox. The Exchange store has a Performance Monitor counter for the number of
quarantined mailboxes. The counter name is MSExchangeIS Mailbox\Quarantined
Mailbox Count.

The Exchange store also writes an event whenever it quarantines a mailbox, with
details about which mailbox and what time. The event 10018 identifies a
quarantined mailbox.

Return to top
Database Repair

In Exchange 2010 Service Pack 1 (SP1), you can use the New-MailboxRepairRequest
cmdlet to detect and repair mailbox corruptions. You can run this cmdlet against a
specific mailbox or against a mailbox database. While this task is running, mailbox
access is disrupted for the mailbox being repaired. If you run this cmdlet against a
mailbox database, only access to the mailbox being repaired is disrupted. All other
mailboxes in the database remain operational. For more information, see Create a
Mailbox Repair Request.

The New-MailboxRepairRequest cmdlet detects and repairs the following types of

mailbox corruptions:

Search folder corruptions (using the SearchFolder value of the CorruptionType

parameter)

Aggregate counts on folders that aren't reflecting correct values (using the
AggregateCounts value of the CorruptionType parameter)

Views on folders that aren't returning the correct content (using the FolderView
value of the CorruptionType parameter)

Provisioned folders incorrectly pointing to parent folders that aren't provisioned

(using the ProvisionedFolder value of the CorruptionType parameter)

After you run the New-MailboxRepairRequest cmdlet, you can use Event Viewer to
view the details of the request. For more information, see View Mailbox Repair
Request Entries in Event Viewer.

You can also use the New-PublicFolderDatabaseRepairRequest cmdlet to detect and

fix replication issues in the public folder database. Public folders in the public folder
database can still be accessed while the request is running. However, access isn't
available to the public folder currently being repaired. For more information, see
Create a Public Folder Database Repair Request.

Return to top
Time-Out Detection and Reporting

Another indication of an unhealthy Exchange store is that threads are either

deadlocked or otherwise not making any progress. If there are more than five
threads on a single mailbox, ten threads on a single database, or twenty threads on
a single server that hasn't made progress in one minute, a time-out is reported on
the server. The performance counter that indicates detected time-outs is
MSExchangeIS\ RPC Request Timeout Detected.

The Exchange store also writes the following events to the server:

10025, which reports a time-out on the Exchange server

10026, which reports a time-out on the database

10027, which reports a time-out on an individual mailbox

If the time-out is detected on a single mailbox, the mailbox is considered potentially

poison, and is handled similar to a failure by increasing the CrashCount key. This
makes it susceptible to being quarantined.

Return to top
Low Disk Space on Database Logs or Database Drives

When the Exchange store detects that the space available on a log or database
drive is below 1 GB, it cuts off all transport delivery to that database. This is to
prevent a disk running out of space. When a disk runs out of space, the database
can't be mounted or debugged. The database space also can't be reclaimed. This is
a self-protecting mechanism that only occurs if you don't react to the space issue
warnings from your monitoring infrastructure.

When the disk space goes above 1.5 GB, the Exchange store allows deliveries to
continue. The following performance counters indicate this behavior:

MSExchangeIS Mailbox\ Delivery Blocked: Low Database Space

 MSExchangeIS Mailbox\ Delivery Blocked: Low Log Space

The Exchange store also writes the following events to the server:

10014, which indicates low disk space on the log

10015, which indicates low disk space on the database

If you encounter low disk space issues, you can perform the following actions to
correct the issue:

Delete content from mailboxes. Specifically, you can delete messages from the
Deleted Items and Sent Items folders.

Purge items from the Recoverable Items folder. For details, see Clean Up the
Recoverable Items Folder.

Run database maintenance. For details, see Maintain Mailbox Databases.

Purge transaction logs. For details, see Understanding High Availability Factors.

Enable circular logging. For details, see Configure Mailbox Database Properties.

Change the database path to a hard disk drive that has more space. For details,
see Move the Mailbox Database Path for a Mailbox Database Copy.

Return to top
Exchange Store Limits

In Exchange 2010, connection and usage limits are placed on the Exchange store to
prevent a single application or a single user from using all the available connections
to the Exchange store. If a single user or application uses all the connections, other
users or applications won't be able to access the Exchange store, which can result
in downtime.