XADM: How Circular Logging Affects the Use of Transaction Logs

Zavrnitev odgovornosti za umaknjeno vsebino KB

Ta članek govori o izdelkih, za katere Microsoft ne ponuja več podpore. Zato je ta članek na voljo »tak, kot je«, in ne bo več posodobljen.


Exchange Server and Exchange 2000 Server store data in Jet databases. To commit this data to the database, Exchange writes each transaction to a
transaction log. In the background, these transaction logs are committed to
the 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.

More Information

Transaction Logs and How Exchange Uses Them

Transaction logs are files that Exchange uses to commit data (e-
mail messages, user additions, creation of folders, and so forth) to the
corresponding database file on disk. For example, in the Exchsrvr\Mdbdata
folder you may see files such as Edb.log, Edb00001.log, Priv.edb, and
Pub.edb. The Edb*.log files are the transaction logs and the *.edb files
are the information store database files. (The Priv.edb file is the private
information 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 more
transactions are created.

Exchange uses these write-ahead transaction logs to ensure
up-to-the-second recoverability of the database. Each (operation)
transaction is written to a transaction file and to the database cache, and
eventually to the database. After data is written to the database, a
checkpoint (Edb.chk) is advanced. This checkpoint marks the position in the
log files at which the database is in a consistent state. Thus, in the
set of transaction logs, there is a portion that can be considered active
and a portion that can be considered inactive. If an event such as a power
outage causes the system to fail, Exchange goes into automatic
recovery when the system is restarted. This entails rolling forward through
the transactions in the existing log files to the checkpoint.

As described earlier, during recovery, the inactive portion of each log is
not used; however, the logs can prove to be valuable when media failures
occur. If the transaction logs are hosted on a different medium than the
database and the medium containing the database fails, it is possible to
generate a complete recovery by restoring the last full backup on the new
medium and then rolling forward through all the log files. Essentially, the
checkpoint gets moved back from its location relative to the database on
the disk that failed. Media failure is not a common scenario, but this is
the only way (other than a fault tolerant solution, such as mirroring) that
Exchange can recover from media failures.

When circular logging is disabled, the system continues to create log
files 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 On

NOTE: 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 as
usual; however, after the checkpoint (Edb.chk) file has been advanced, the
inactive portion of the transaction log is discarded and overwritten.
Typically, this represents the majority of the potential log data, because
by definition, the total size of the active transactions is less than
the 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-MB
attachment, 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, and
Edb00004.log. After the transaction is processed completely, these log
files remain until a full backup is performed on the database, at
which time they are removed. If the number of log files generated with
circular logging enabled is equal to or greater than four (not including
Edb.log) the logs remain until a full backup is performed.

When circular logging is enabled, high-volume conditions also cause the
number of log files to increase. Because the inactive portion of a
transaction 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 that
cause the transactions not to be completed in a timely manner, and the
Edb.log files being held open exclusively by another process other then Jet
(for example, backup programs, copying operations, and so on).

ID članka: 147524 – Zadnji pregled: 8. okt. 2010 – Revizija: 1

Povratne informacije