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.

	Copy Code
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.

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

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

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

Acting on the Poison Mailbox

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.

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.

Reporting and Alerts

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

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