Lost Log Resilience and Transaction Log Activity in Exchange 2010

[This is pre-release documentation and subject to change in future releases. This topic's current status is: Writing Not Started.]

This topic discusses a new feature called lost log resilience (LLR) and a companion function called log roll. These features are new in Microsoft Exchange Server 2007 and are present on all Mailbox servers. However, the behavior of these features depends on the configuration of the Mailbox server.

Lost Log Resiliency

In Exchange 2007, a new feature of Extensible Storage Engine (ESE), LLR, enables you to recover Exchange databases even if one or more of the most recently generated transaction log files have been lost or damaged. LLR is an internal ESE component that works with cluster continuous replication (CCR). Specifically, LLR works with CCR by enabling a mailbox database in a CCR environment to mount even when recently generated log files are unavailable. The most common cause of this condition is a lossy failover, which is also known as a scheduled outage. For more information about lossy failovers, see Scheduled and Unscheduled Outages. LLR is enabled only on the active node in a CCR environment. LLR is not used by the passive node, and the passive node is always kept as up to date as possible.

LLR works by delaying writes to the database until the specified number of log generations have been created. The order of write operations of Exchange data is always memory, log file, and then database. LLR delays updates to the database for a short time. In the event of a failover, if the maximum number of lost logs has not been reached or exceeded, the database will mount.

An administrator determines the maximum number of logs that can be lost before the database cannot be mounted by setting the AutoDatabaseMountDial parameter. This parameter, which is represented in the Active Directory directory service by an Exchange attribute called msExchDataLossForAutoDatabaseMount, has three values: Lossless, Good Availability, and Best Availability. Lossless is 0 logs lost, Good Availability is 3 logs lost, and Best Availability, which is the default, is 6 logs lost. For detailed steps about how to configure these values, see How to Tune Failover and Mount Settings for Cluster Continuous Replication. When configuring the system for Good Availability or Best Availability, do not use spaces (for example, use GoodAvailability and BestAvailability).

By default, LLR is enabled and active on all Exchange 2007 Mailbox servers. However, the number of logs that can be lost is configurable only for clustered mailbox servers that have been deployed in a CCR environment. The AutoDatabaseMountDial parameter is used only by clustered mailbox servers in a CCR environment.

Transaction Log Roll

A mechanism called log roll is used to further minimize data loss. Log roll works by periodically closing the current transaction log file and creating the next generation. This mechanism helps LLR, and in turn CCR, to reduce database inconsistency that results from lost log files. It is intended primarily to minimize data loss after a lossy failover.

Rolling a log forward means that the current (Exx.log) log file is closed and a new transaction log file is generated, even if the current log file is not full. For more information about transaction logging, see Understanding Transaction Logging.

Log Roll Size

For a log roll of significant size to develop in a storage group, the following conditions must be met:

• The storage group must have a mailbox database.
• The storage group must have little user activity that creates transaction logs.
• The storage group must have one or more mailboxes that are frequently logged on to by a process or by an application.

The maximum number of log files that will be generated each day for an idle storage group depends on the configuration of the Mailbox server. The maximum number of log files per idle storage group for each Mailbox server configuration is listed in the following table.

Maximum number of log files per idle storage group for each Mailbox server configuration

Mailbox servers generally create more transaction logs than the value shown in the preceding table because of user activity, online maintenance, and other factors.