XADM: How Circular Logging Affects the Use of Transaction Logs
This article was previously published under Q147524
This article has been archived. It is offered "as is" and will no longer be updated.
Exchange Server and Exchange 2000 Server store data in Jet databases. To commit this data to the database, Exchange writes each transaction to atransaction log. In the background, these transaction logs are committed tothe database. Exchange has a circular logging option that, when enabled, limits the amount of disk space that is used by these transaction logs. This article describes the ways in which circular logging affects the use of transaction logs in Exchange.
Transaction Logs and How Exchange Uses ThemTransaction logs are files that Exchange uses to commit data (e-mail messages, user additions, creation of folders, and so forth) to thecorresponding database file on disk. For example, in the Exchsrvr\Mdbdatafolder you may see files such as Edb.log, Edb00001.log, Priv.edb, andPub.edb. The Edb*.log files are the transaction logs and the *.edb filesare the information store database files. (The Priv.edb file is the privateinformation store and the Pub.edb file is the public information store.) The most current transactions are stored in the Edb.log file; when the Edb.log file reaches 5 megabytes (MB) in size, a file called Edbtmp.log is created to accept incoming transactions and the Edb.log file is renamed to Edb00001.log. After the Edb.log file is renamed, the Edbtmp.log file is then renamed Edb.log. This process is repeated each time the Edb.log file reaches 5 MB in size. Therefore, the log files build up as more and moretransactions are created.
Exchange uses these write-ahead transaction logs to ensureup-to-the-second recoverability of the database. Each (operation)transaction is written to a transaction file and to the database cache, andeventually to the database. After data is written to the database, acheckpoint (Edb.chk) is advanced. This checkpoint marks the position in thelog files at which the database is in a consistent state. Thus, in theset of transaction logs, there is a portion that can be considered activeand a portion that can be considered inactive. If an event such as a poweroutage causes the system to fail, Exchange goes into automaticrecovery when the system is restarted. This entails rolling forward throughthe transactions in the existing log files to the checkpoint.
As described earlier, during recovery, the inactive portion of each log isnot used; however, the logs can prove to be valuable when media failuresoccur. If the transaction logs are hosted on a different medium than thedatabase and the medium containing the database fails, it is possible togenerate a complete recovery by restoring the last full backup on the newmedium and then rolling forward through all the log files. Essentially, thecheckpoint gets moved back from its location relative to the database onthe disk that failed. Media failure is not a common scenario, but this isthe only way (other than a fault tolerant solution, such as mirroring) thatExchange can recover from media failures.
When circular logging is disabled, the system continues to create logfiles until a backup is completed. Backing up Exchange is the preferred method of saving the log files and removing these logs from the disk to free up space.
Effect of Having Circular Logging Turned OnNOTE: Circular Logging is turned on by default for Exchange Server 5.5 and earlier, but circular logging is turned off by default for Exchange 2000 Server.
When circular logging is on, Exchange writes transaction logs asusual; however, after the checkpoint (Edb.chk) file has been advanced, theinactive portion of the transaction log is discarded and overwritten.Typically, this represents the majority of the potential log data, becauseby definition, the total size of the active transactions is less thanthe total amount of random access memory (RAM) on a given computer. Thus, when circular logging is on, the system still has complete recoverability with respect to hard and soft failures. The element that is sacrificed is the extra protection against media failure. Also, because the transaction logs are used for incremental and differential backups, these backup methods are no longer valid. If you try to do an incremental or a differential backup on a server that has circular logging enabled, Microsoft Windows NT Backup generates an error message that informs you that the incremental or differential backup cannot be done.
When circular logging is enabled you can see more than one transaction log in the log directory. For example, if a user sends a message with a 25-MBattachment, because the maximum log file size is 5 MB, four logs are likely to be created to process this transaction in addition to the Edb.log file. That is, you see Edb00001.log, Edb00002.log, Edb00003.log, andEdb00004.log. After the transaction is processed completely, these logfiles remain until a full backup is performed on the database, atwhich time they are removed. If the number of log files generated withcircular logging enabled is equal to or greater than four (not includingEdb.log) the logs remain until a full backup is performed.
When circular logging is enabled, high-volume conditions also cause thenumber of log files to increase. Because the inactive portion of atransaction log is only discarded and reused after the Edb.chk file has moved past the inactive portion, many transactions may build up in the logs before they can be processed. If the total number of unprocessed transactions exceeds 5 MB and more continue to build up, another log file (for example, Edb00001.log) is created to hold these transactions. If the high-volume conditions continue, the log files continue to increase in number until the transactions can be processed completely. After the transaction processing catches up and the Edb.chk file is advanced past the transactions in these log files, these log files become inactive and again are not be removed until a full backup is performed. Other possible causes of log files growing with circular logging enabled are faulty small computer system interface (SCSI) controllers or hard drives thatcause the transactions not to be completed in a timely manner, and theEdb.log files being held open exclusively by another process other then Jet(for example, backup programs, copying operations, and so on).
Article ID: 147524 - Last Review: 12/04/2015 14:14:29 - Revision: 4.3
Microsoft Exchange 2000 Server Standard Edition
- kbnosurvey kbarchive kbenv kbinfo KB147524