Escolar Documentos
Profissional Documentos
Cultura Documentos
UnderstandingtheExchange2010Store:Exchange2010Help
Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2
Topic Last Modified: 20131025
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 MicrosoftExchange 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
Description
https://technet.microsoft.com/enus/library/bb331958(d=printer,v=exchg.141).aspx
1/6
11/08/2016
UnderstandingtheExchange2010Store:Exchange2010Help
Exchange
database
.edb
These files are the repository for mailbox data. They're accessed by the Extensible Storage Engine ESE directly and have a Btree structure
designed for quick access. This enables users to access any page of data within one input/output I/O cycle, which is a fourfold increase
compared to Microsoft Exchange Server 2007. Exchange databases are composed of multiple Btrees, 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
Basename:e00
Logfile:e00.log
lGeneration:11(0xB)
https://technet.microsoft.com/enus/library/bb331958(d=printer,v=exchg.141).aspx
2/6
11/08/2016
UnderstandingtheExchange2010Store:Exchange2010Help
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 NOTAVAILABLE. 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 selfcontained 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.
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.
Caution:
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
3/6
11/08/2016
UnderstandingtheExchange2010Store:Exchange2010Help
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 timeouts, use report and alert features to signal an unhealthy Exchange store state, and detect and repair mailbox database and public folder database
issues.
https://technet.microsoft.com/enus/library/bb331958(d=printer,v=exchg.141).aspx
4/6
11/08/2016
UnderstandingtheExchange2010Store:Exchange2010Help
<Server Name>\Private{db guid}\MailboxQuarantineDurationInSeconds.
Database Repair
In Exchange 2010 Service Pack 1 SP1, you can use the NewMailboxRepairRequest 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 NewMailboxRepairRequest 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 NewMailboxRepairRequest 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 NewPublicFolderDatabaseRepairRequest 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
https://technet.microsoft.com/enus/library/bb331958(d=printer,v=exchg.141).aspx
5/6
11/08/2016
UnderstandingtheExchange2010Store:Exchange2010Help
This is a selfprotecting 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.5GB, 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
Community Additions
9/4/2013
2016 Microsoft
https://technet.microsoft.com/enus/library/bb331958(d=printer,v=exchg.141).aspx
6/6