Exchange 2007 SP1 CCR / LCR / SCR – Transaction Log Roll

  • Article

Recently there have been some questions about transaction log rolling and continuous replication.  In some cases these questions often surround storage group copy status showing an initializing state (https://blogs.technet.com/timmcmic/archive/2009/01/26/get-storagegroupcopystatus-initializing.aspx).

Under normal circumstances, the only time that log would roll, is when we’ve reached a log full condition.  If the server is being utilized, this is not a problem, as logs will roll naturally as the server processes activity.

There are times though where the server is relatively idle.  This would mean the current log generation would not receive enough transaction activity against it to cause it to roll over.  This is where “transaction log roll” is important.  If the current log file (ENN.log) contains a durable (or hard) commit, and that log is not filled in a period of time, it will be rolled over and shipped to the other side.  (This is not an immediate process, if we rolled a log over every time there was a durable (hard) commit we'd generate a ton of logs).   The article referenced above gives examples of how to calculate the time that a log would roll over should it contain a durable (hard) commit.  The article above also contains the following text highlighting this behavior:

“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.”

This information is important to us for several reasons.

The first is generally if logs roll why do my storage groups stay initializing for hours at a time.  The answer is because the current log does not contain a durable commit.  If you were to restart the replication service or suspend and resume a replication instance manually the first replication state you will encounter is initializing.  We remain in initializing until a log is generated, copied, inspected, and put out for replay with divergence information determined.  If no durable (hard) commit exists in the source log stream, the logs may not be rolled over until there is a durable (hard) commit or user activity, which means replication would stay in an initializing state for a while.  My suggestion is, if this is a test environment, simply send mail / dismount the source databases / etc.  In production, I've seen people script email to test mailboxes at a schedule time with a test mailbox located in each database.  This causes a durable commit, which will eventually result in log file roll over and shipment to the other side.

The second reason is that log file roll can cause churn in the log file stream which does not appear normal.  If you reference the link above you can see that an idle storage group could generate up to 960 log files a day.  This is especially true of the storage group contains some type of system mailboxes (which exchange accesses causing a durable commit) or test mailboxes which the user is accessing.  In either scenario, there may not be enough load by either process to force log roll to occur naturally, so Exchange rolls the log for you at a certain time.  This causes some concern, especially when looking at the log file drive on a test server etc and questioning why so many logs were generated.  IE - there wasn't enough traffic to generate 960 megs of logs, which is probably correct, but there was enough traffic to put a durable commit into each of those 960 logs such that we rolled and shipped them without being full in attempts to keep both sides up to date.

The third reason I pointed this out is that there seems to be confusion on when log roll should occur.  This leads to people believing the log roll should occur no matter what, when as indicated it should only occur if the log contains a durable (hard) commit. 

There are other operations besides user activity or a durable (hard) commit which will cause the current transaction log to roll:

  • An attachment record is created in a log when a database is mounted.
  • A VSS backup occurs of the active node.
  • A VSS backup occurs of the passive node.
  • An online streaming backup occurs of the active node.

I hope everyone finds this information helpful.