Clearing the confusion around circular logging

Because Microsoft's circular logging recommendations have changed over the years based on Exchange Server version changes, there is a lot of contradictory information out there on the topic. This article explains what circular logging is and the pros and cons of using it to manage Exchange transaction logs.

An issue that commonly confuses new Exchange Server administrators is circular logging. Because Microsoft's circular logging recommendations have changed over the years based on Exchange Server version changes, there is a lot of contradictory information out there on the topic. In this article, I explain what circular logging is and the pros and cons of using it.

By submitting your personal information, you agree to receive emails regarding relevant products and special offers from TechTarget and its partners. You also agree that your personal information may be transferred and processed in the United States, and that you have read and agree to the Terms of Use and the Privacy Policy.

A crash course in Exchange transaction logs

Before you can understand circular logging, you need to know what transaction logs are and how Exchange Server uses them. Information that needs to be added to a mailbox database is first written to an Exchange transaction log. The contents of that transaction log are later written to the Exchange Server database.

Exchange Server writes data to transaction logs first for a couple of reasons. First, it's more efficient to write data to a transaction log than wait for database activity to stop so a change can be written directly to the database.

Primarily, though, transaction logs are used as part of the Exchange Server backup process. Volume Shadow Copy Services aside, you can't back up an open file. If data were written directly to the Exchange database, you would have to close the database before you could back it up, which means it would be unavailable to users during that period of time.

Microsoft chose to use the transaction log model, so users can still access Exchange Server during a backup. The data is simply written to the transaction logs rather than to the Exchange database. When the database is backed up, the transaction logs are backed up as well and their contents committed to the database.

Normally, after a backup completes, Exchange transaction logs accumulate until the next backup. If you have to restore the database, those accumulated transaction logs can be used to bring Exchange Server database back to a current state.

The mechanics of circular logging

Circular logging was introduced in a much earlier version of Exchange Server as a method for conserving disk space. It prevents Exchange transaction logs from filling up your hard disk by limiting the maximum number of transaction logs in use at any given time.

In most cases, only four transaction logs will be used at a time. Since transaction logs are 5 MB in size, they will consume 20 MB of disk space if circular logging is enabled. Once the fourth transaction log fills up, Exchange Server makes sure that the first transaction log created has been flushed, and then replaces it with an empty log file that will store the next set of transactions.

For example, Exchange will initially create the following log files: E0000001.LOG, E0000002.LOG, E0000003.LOG, and E0000004.LOG. Exchange Server will fill up E0000001.LOG first before moving on to E0000002.LOG. When E0000004.LOG is full, the E0000001.LOG file is erased and replaced with E0000005.LOG.

Advantages and disadvantages of circular logging

Circular logging's main drawback is that it affects the ability to back up and restore data. When enabled, you can only perform full backups of the Exchange database. You cannot perform incremental or differential backups.

Furthermore, if you ever have to restore a backup, you will almost always lose any data that has been added to the server since the backup was made, because of the limited amount of data that is stored in the transaction logs when circular logging is enabled.

You might be wondering why Microsoft would create a feature that limits the ability to recover from a disaster. As I explained earlier, circular logging is left over from an ancient version of Exchange Server. Today, hard disks tend to be massive, so it makes no sense to use circular logging unless your server is running extremely low on hard disk space.

How to enable or disable circular logging

Clearly, circular logging on an Exchange 2003 server is almost always a bad idea. As such, it is disabled by default. But if you want to verify that it is disabled, open Exchange System Manager and navigate through the console tree to Administrative Groups -> your administrative group -> Servers -> your server -> the storage group you want to check. Right click on the storage group, select Properties, and verify that the "Enable Circular Logging" checkbox is not selected.

About the author: About the author: Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Exchange Server, and has previously received Microsoft's MVP award for Windows Server and Internet Information Server (IIS). Brien has served as CIO for a nationwide chain of hospitals and was once responsible for the Department of Information Management at Fort Knox. As a freelance technical writer, Brien has written for Microsoft, TechTarget, CNET, ZDNet, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal Web site at http://www.brienposey.com.

It didn't seem like you pointed out the advantages of circular logging at all. Enabling it completely removes the threat of filling up a disk with transaction logs. For servers that perform bridgehead type functions and do not store any mail so-to-speak, it's often the case that a database would not have to be restored in a disaster situation (create a new one and you're up). If there's no need to restore a database, circular logging becomes more desirable. Pat P.

******************************************

Granted, circular logging does have its place. If there were never a need for circular logging, Microsoft would not have created it in the first place. When I wrote the article, I did so under the assumption that the server in question would be hosting mailboxes and/or public folders, would have plenty of disk space, and would be backed up regularly. Brien Posey, tip author

******************************************

Great article!

Is it also a good practice to enable circular logging if you have deployed a front-end server that doesn't contain any mailboxes? Ted O.

******************************************

Front-end servers do not contain databases, and therefore there is no need to enable or disable circular logging. Brien Posey, tip author

******************************************

What about using circular logging on front-end Outlook Web Access (OWA) servers in a DMZ?

Since there is no user data on the front-end server in this scenario, you could question the need to run an Exchange aware backup on these servers. They are not the first servers in the site and they don't have any databases, so recovery of these servers is much simpler. OWA servers don't need the same beefy disk requirements as the back-end Exchange servers, therefore, circular logging makes sense in this scenario. It's an economy of scale: mirrored drives, Exchange Standard Edition, low backup expense. Dave C.

******************************************

This is a perfectly valid point. Again though, I wrote the article under the assumption that the server in question contained databases filled with mailboxes or public folders. Brien Posey, tip author

Please let others know how useful this tip is via the rating scale below. Do you have a useful Exchange Server or Microsoft Outlook tip, timesaver or workaround to share? Submit it to SearchExchange.com. If we publish it, we'll send you a nifty thank you gift.

E-Handbook

E-Handbook

0 comments

E-Mail

Username / Password

Password

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy