In Exchange 2007, an internal component of Extensible Storage Engine (ESE) called 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. By default, LLR is enabled on all Exchange 2007 mailbox servers. LLR enables a mailbox database to mount even when recently generated log files are unavailable. One cause of unavailable log files is a lossy failover in a cluster continuous replication (CCR) environment, which is also known as an unscheduled outage. For more information about lossy failovers, see Scheduled and Unscheduled Outages. For details about recovering a database with missing log files, see Eseutil /R Recovery Mode.

Note:
In a continuous replication environment, LLR is enabled only for the active copy of a database. LLR is not used by the passive copy because passive databases are always kept as up-to-date as possible.

The order of write operations of Exchange data is always memory, log file, and then database file. LLR works by delaying writes to the database until the specified number of log generations have been created. LLR delays recent updates to the database file for a short time. The length of time that writes are delayed depends on how quickly logs are being generated.

In the event of a failover, the passive copy of the databases can be automatically mounted by the Microsoft Exchange Information Store service if the number of lost logs is fewer than the allowable amount as configured by an administrator. An administrator determines the maximum number of logs that can be lost before the database cannot be mounted on a failover 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 you configure the system for Good Availability or Best Availability, do not use spaces (for example, use GoodAvailability and BestAvailability).

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 data loss that results from lost log files, primarily after a lossy failover.

Important:
The log roll mechanism does not generate transaction logs in the absence of user or other database activity. In fact, log roll is designed to occur only when there is a partially filled log.

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.

The log roll behavior is based on the value of the LLR depth. In a CCR environment running Exchange 2007 RTM, the LLR depth is a numeric value equal to 1 plus the tolerable number of lost logs, as specified by the value of the AutoDatabaseMountDial parameter. For example, if the value of the AutoDatabaseMountDial parameter is 6, indicating the system is configured for Best Availability, the value of the LLR depth is 7.

In a CCR environment running Exchange 2007 SP1, the LLR depth is hard-coded with a value of 10, regardless of the value of the AutoDatabaseMountDial parameter.

In both Exchange 2007 RTM and SP1, the LLR depth is hard-coded with a value of 1 for all mailbox servers that are not in CCR environments (for example, stand-alone mailbox servers with or without LCR and single copy clusters).

Log roll will occur after the system has been idle for a calculated period of time. To calculate when log roll should occur, the system uses the following formula:

[15 (minutes) ÷ LLR Depth value] = Frequency of log roll activity (in minutes)

You can then divide 1,440 (the number of minutes in each day) by the frequency of log roll activity to determine the maximum number of log files per storage group that would be generated each day as a result of log roll activity.

For example, in CCR environments running Exchange 2007 SP1, the LLR depth is 10. Thus, log roll activity occurs every 1.5 minutes, and the maximum number of log files generated per storage group each day as a result of log roll activity is 960.

 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 Exchange 2007 RTM mailbox server configuration

Mailbox server configuration	Maximum number of transaction log files generated per day by an idle storage group
Stand-alone (with and without LCR) Single copy cluster CCR with Lossless availability	96
CCR with Good Availability	384
CCR with Best Availability	672

Maximum number of log files per idle storage group for each Exchange 2007 SP1 mailbox server configuration

Mailbox server configuration	Maximum number of transaction log files generated per day by an idle storage group
Stand-alone (with and without LCR) Single copy cluster	96
CCR with Lossless, Good, and Best Availability	960

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