Understanding the Exchange 2010 Store

  • Article

Applies to: Exchange Server 2010

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

Logical Components of the Exchange Store

File Structure of the Exchange Store

Understanding Transaction Logging

Extensible Storage Engine

Storage Features in Editions of Exchange 2010

Improvement to Store Health and Resilience

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   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 that are generated when a new mailbox is created for that user. A mailbox database is stored as an Exchange database (.edb) file.
  • Public folder databases   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, which are mailbox databases and public folder databases. In addition, Exchange 2010 stores data in the following specialized set of data files. Unless you are backing up or restoring data, you rarely interact with these files directly.

  • Exchange database (.edb) files   These files are the repository for mailbox data. They are accessed by the Extensible Storage Engine (ESE) directly and have a B-tree structure designed for quick access, thereby enabling users to access any page of data within four I/O cycles. The Exchange database is composed of multiple B-trees, with ancillary trees that work with the main tree by holding indexing and views.
  • Transaction logging (.log) files   Exchange 2010 writes operations (such as creating or modifying a message) to a log (.log) file for that database. Committed transactions are later written to the database itself in an .edb file. This approach guarantees that all completed and in-progress transactions are logged, so data integrity is maintained in case of a service interruption. The databases share a single set of transaction logs that are named with consecutive numbers (for example, E0000000001.log and E0000000002.log).
  • Checkpoint (.chk) files   These files store information that indicates when a transaction is successfully saved to the database files on the hard disk. Exchange 2010 uses checkpoint files to allow an instance of the ESE to automatically replay log files into an inconsistent database when recovering from a service interruption, starting with the next unwritten transaction. The checkpoint files are placed in the same log location as the log files.

Return to top

Understanding Transaction Logging

This section describes the details of transaction logging in Exchange 2010 and includes a brief description of circular logging.

Exchange transaction logging is a robust recovery mechanism of the ESE that's 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.

Exchange Transaction Logging

Before changes are made to an Exchange database file, Exchange writes the changes to a transaction log file. After a change has been 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 have been secured to the transaction log, but before the changes have been written to the database file.

Exchange employs a sophisticated internal memory management system that's tuned for high performance and can efficiently manage the caching of dozens of gigabytes (GBs) of database pages. Therefore, physically writing out 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, 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 that's 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 simply 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 is a checkpoint file for each log stream, and a separate log stream for each database. All the databases share a single log stream. Thus, a single log file often contains operations for multiple databases.

Log files are numbered in a hexadecimal manner, so the log file after E0000000009.log is E000000000A.log, 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.

Note

Eseutil is located in the Exchange default install folder, which is <SystemDrive>:\Program Files\Microsoft\Exchange Server\V14\Bin. For more information, see Eseutil.

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. You can, however, 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 for you to understand Exchange file headers. If you understand the 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)

Here's what this example is telling you:

  • Log file   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.
  • lGeneration   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 is E000000000B.log.
  • Checkpoint   The Checkpoint value in the 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. 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. You'll seldom have a practical need for this information.
    If the checkpoint file has been destroyed, the Checkpoint value reads NOT AVAILABLE. 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 and completely 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 even move the database files to a different server that has existing log files, and the databases would attach themselves to a different log stream.

Note

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.

Warning

If you have to repair a database, some data is lost. Data loss is frequently minimal; however, it may be catastrophic. After running Eseutil /p on a database, you should completely repair the database with the following two operations: First, run Eseutil /d to defragment the database. This operation discards and rebuilds all database indexes and space trees. And then, run Eseutil /r to repair the database.

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.

Circular Logging

Although we don't recommend it as a best practice, 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 has been committed 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. Therefore, in a normal production environment, circular logging isn't recommended.

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 megabyte (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.

Return to top

Extensible Storage Engine

Exchange mailbox databases and the queue on Hub Transport servers and Edge Transport servers use the ESE database. ESE is a multi-user, 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

Storage Features 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 five databases. Exchange 2010 Enterprise Edition supports 100 databases.

Return to top

Improvement to Store Health and Resilience

The Exchange store has improved in its ability to handle poison mailboxes and thread time-outs. Improvements have also been made in the reporting and alert features that signal an unhealthy Exchange store state.

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 two types of events for which the Exchange store tags a mailbox as a potential threat:

  • If a thread that's 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 as such. This information is stored in the registry. The Exchange store also keeps time stamp information on when the mailbox was identified as a potential threat.

During a database mount, the Exchange store reads the time at which 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, so even during an Exchange store failover, the other servers have this information.

The registry path used for isolating the poison mailbox is HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<Server Name>\Private-{db guid}\QuarantinedMailboxes\{mailbox guid}.

CrashCount and LastCrashTime are the keys used in this registry path.

MailboxQuarantineCrashThreshold is the setting that relates to how many failures lead to quarantining a mailbox. MailboxQuarantineDurationInSeconds is the setting that you use to indicate how long a mailbox should stay in quarantine. The default values for these keys are three failures for MailboxQuarantineCrashThreshold and six hours for MailboxQuarantineDurationInSeconds.

These keys are in the registry path HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<Server Name>\Private-{db guid}\QuarantinedMailboxes.

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 (Content Index, Assistants, and so forth) 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 amount of time specified in MailboxQuarantineDurationInSeconds since the time of its last failure, it's released from quarantine automatically.

Resetting the Quarantined Mailbox

When the cause of the poison mailbox has been identified and corrected, you should reset the registry key for the quarantined mailbox 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 hasn't been debugged and fixed within that time period, this may lead to another set of failures before the mailbox/message is quarantined again.

Note

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}\QuarantinedMailboxes\MailboxQuarantineDurationInSeconds.

Quarantined Mailbox Reporting and Alerts

You can use the Get-MailboxStatistics cmdlet to report on 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 was quarantined and when it was quarantined. Event 10018 identifies a quarantined mailbox.

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:

  • Event 10025   Reports a time-out on the Exchange server
  • Event 10026    Reports a time-out on the database
  • Event 10027   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. This action makes the mailbox susceptible to being quarantined.

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 (or databases). This action prevents a disk from 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 triggers if you don't react to the space issue warnings from your monitoring infrastructure.

The Exchange store writes the following events to the server:

  • Event 10014   Indicates low disk space on the log
  • Event 10015   Indicates low disk space on the database

When the disk space is below 1 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

Return to top