I get asked the question quite a bit, and, normally my response is go and Google it. The other day, my deputy manager had a problem with one of our Exchage servers (disk space) and he was looking at enabling Circular logging in order to sort out the problem.

As a result I tought that I would post a little bit about CL and what it can mean for your Exchange server.

In order to understand Circular logging, perhaps it is best to understand Exchange server Transaction logs in general.

Exchange uses transaction logs to add information such as e-mails, users and changes to the relevant database files on the disk of your Exchange server. In a default Exchange installation you will find them in the C:\program files\exchsrvr\mdbdata folder (they look like EBD.log and Edb0xxxxx.log), the other files in that folder are typically the Priv1.edb/Pub1.edb and Priv1.stm/Pub.stm files (Exchange Database and Streaming file plus the equivalent public folder databases) and an Edb.chk (checkpoint) file – more on this later.

The most recent transactions (data changes) are held in the Edb.log file when this file reaches around 5 MB in size another file called Edbtmp.log is created which temporarily takes over from the Edb.log accepting new changes to the database whilst the Edb.log is renamed to Edb00001.log.

After the Edb.log file has been renamed, the Edbtmp.log is renamed to Edb.log and then the process continues at every 5 Mb interval. – got that? – nope clear as mud I guess, think of it this way – when the Edb.log file gets to 5 MB another file comes in that takes over from it, whilst Edb.log gets a new name, then the interim file becomes the new Edb.log.

Exchange uses a process which is called “read ahead” transaction logs, this means that each transaction is placed within the log, the database cache and then into the relevant database itself. When the operation is written to the database the checkpoint (Edb.chk) is incremented which signals the position in the log files where the database is in a consistent (or clean) state – more on that in a minute.

This means that any amount of your transaction logs can be considered either active (not committed) or inactive (committed), if for any reason the store service is terminated (crash, power cut etc) Exchange will automatically recover the next time the server starts – this happens by Exchange “rolling forward” all of the transactions in the logs which bring us up to the marker in the checkpoint file (Edb.chk).

Logs will continue to be created until a full online backup of Exchange has been completed (using NTBackup or another vendors product) where the process of backing up will commit all transactions to the database in the log files, and then flush (delete) the files and then the system is ready to start again. It is at this point that I will say that UNDER NO CIRCUMSTANCES SHOULD YOU EVER MANUALLY DELETE THE TRANSACTION LOGS it is possible to identify unused logs – but – it is much easier to allow a backup product to do it for you.

Ok, I hear you ask, but what is Circular Logging?, well when Circular logging is enabled Exchange behaves in exactly the same way – but the key difference is when the checkpoint file is incremented the inactive part of the transaction log is overwritten by new transactions (rather than a new log being created). Now this in some aspects is Ok as you are still fairly protected in regard to hardware and software failures, but, you are not protected against media failures.

It is still possible to see more than one transaction log in the directory (for example if a large number of large sized mails are being sent – each log can only be 5 MB so if a 6 MB mail is sent that will produce an additional log) – and again these logs will not be cleared until a full online backup is completed. However generally speaking when Circular logging is enabled less log files are created.

Consistencies;

If a database has not closed down gracefully it is said to be inconsistent. When this happens the database believes that it is still in communication with the transaction logs, however not all of the information from the logs may not have been committed to the database.

When the Database next starts up this situation is noticed, and the STORE process will attempted to commit the missing data from the logs (this is called replaying). If however the some logs that are required are missing the Database will not mount, and you will be left in the situation of having to use ESEUTIL to recover the database or return to a recent backup where the database was consistent (this is beyond the scope of this article – but I will cover it at some point).

Summary;

Circular logging may at first glances seem like a bad idea, but it does have its uses in some Exchange environments – for example Front-End Servers (where there is no mailbox data) and relay servers (again no mailboxes) can make great use of it – however, for Database servers it is essential that Circular logging is not used as it will put you in the position of not having full control over your restoration processes.