![Scott Schnoll [MSFT]}](http://i1.social.s-msft.com/profile/u/avatar.jpg?displayname=scott+schnoll+%5bmsft%5d&size=large){kind=avatar}
In the transaction logging mechanism used by Exchange, each database transaction is written first to a log file and then to the database file. When a log file reaches a certain size (1 MB in Exchange 2010), it's renamed with the next generation sequence number, and a new log file is created. Over time, this results in a set of log files known as the log stream. If the Exchange Information Store or Windows stops unexpectedly, the log stream is used to recover the transactions by replaying the data from the log files into the database.
Circular logging is a feature of the Joint Engine Technology (JET) database used by all versions of Exchange Server that can be enabled or disabled by an administrator. When enabled, circular logging allows Exchange to overwrite transaction log files after the data contained in the log files is committed to the database. By enabling it, you can reduce storage space requirements. However, without a complete set of transaction log files, you won’t be able to recover any data more recent than the last full backup. In Exchange Server 5.5 and earlier, circular logging was enabled by default, and starting with Exchange 2000 Server and continuing to Exchange 2010, it is disabled by default.
In Exchange Server 2007, we introduced continuous replication, and a companion feature that came to be known as continuous replication circular logging (CRCL). CRCL is different from JET circular logging. JET circular logging is performed by Information Store, and CRCL is performed by the Microsoft Exchange Replication Service.
We introduced CRCL because JET circular logging can’t really work in a continuous replication environment; it doesn’t generate additional log files and instead overwrites the current log file when needed. In a continuous replication environment, log files are needed for log shipping and replay. As a result, unlike Jet circular logging, when you enable CRCL, the current log file is not overwritten and closed log files are generated for the log shipping and replay process.
Specifically, the Microsoft Exchange Replication Service manages CRCL so that log continuity is maintained and logs are not deleted if they are still needed for replication. The Microsoft Exchange Replication Service and the Microsoft Exchange Information Store service communicate by using remote procedure calls (RPCs) regarding which log files can be deleted.
For truncation to occur on highly available (non-lagged) mailbox database copies, the answer must be "Yes" to the following questions:
- Has the log file been backed up, or is CRCL enabled?
- Is the log file below the checkpoint?
- Do the other non-lagged copies of the database agree with deletion?
- Has the log file been inspected by all lagged copies of the database?
For truncation to occur on lagged database copies, the answer must be "Yes" to the following questions:
- Is the log file below the checkpoint?
- Is the log file older than ReplayLagTime + TruncationLagTime?
- Is the log file deleted on the active copy of the database?
You enable and disable both features the same way; either by using the checkbox on the Maintenance tab of the database Properties dialog that says Enable circular logging, or by using the Set-MailboxDatabase cmdlet with the -CircularLoggingEnabled parameter. When you enable circular logging for a mailbox database, the type of circular logging you get depends on whether or not the mailbox database is replicated using continuous replication:
- If the mailbox database is not replicated, it will use JET circular logging. In this case, enabling or disabling JET circular logging will require a dismount and mount of the database.
- If the mailbox database is replicated, it will use CRCL. In this case, enabling or disabling CRCL takes effect dynamically; there is no need to dismount and re-mount the database.
Because of the differences between JET circular logging and CRCL, there is no way to transition a database between JET circular logging and CRCL or vice versa. As a result, when you add the first passive copy of a database or remove the last passive copy of a database, circular logging (JET or CRCL) must be disabled. Both of these operations result in a transition between a non-replicated database and a replicated database or vice versa:
- If you have circular logging enabled for a non-replicated database and you add your first passive copy, Exchange will block that action to prevent switching from JET CL to CRCL. This behavior is there because we need to prevent logs from being truncated while the new copy seed starts. The newly added passive copy would not seed correctly if required logs were removed.
- Same thing (sort of ) for remove. When you try to remove the last passive copy, that would result in a transition from CRCL to CL, and we block that because that transition would require a dismounting and re-mounting of the active copy of the database.
Where it gets tricky is that in both cases where we block an operation because circular logging is enabled, the error message returned to the administrator is not accurate. It says:
Database "{0}" has circular logging enabled. It is not possible to add or remove database copies while circular logging is enabled. Please disable circular logging before adding or removing mailbox database copies.
In addition, a couple of topics on TechNet also repeated this requirement.
It is actually only when you add the second copy of a database (e.g., add the first passive copy), or when you are trying to remove the last passive copy of a database that we block and display this error message. If you are adding a third or subsequent passive copy, circular logging can remain enabled because adding the copy doesn’t require a transition between the two types of circular logging. Similarly, if you are removing any passive copy except for the last passive copy of a database, circular logging can remain enabled.
The TechNet topics have been updated to reflect this, and those updates will be published with our next document refresh. And I will be updating the string in Exchange 2010 Service Pack 2 to clarify this, as well.