Circular logs and backups of exchange

Many Exchange administrators have a problem with headaches: Log files commandeer disk space.

Disk space is limited; however, as long as Exchange is running, the log file is infinite, although each is only 5 m size, but the production of log files is very impressive, most of the disk space is occupied by log files; Microsoft, when designing Exchange, provides a "Enable circular log "Feature, with this feature enabled, the system will only produce 5 5M of log files, cycle replacement use, log files occupy disk space problem is resolved, but from this moment, you pray to God, pray your Exchange database in your tenure. If there is a happens, the mount does not go up, you find a place to cry! Because you have lost your mail for a while.

I must say that I lost the mail because:

First of all, I do not believe that you have to do time backup;

Second, unless you are lucky that your last backup to now, your exchange has not processed an email.

Third, the database repair or restore is required log file, your 5 circular log can help you how much?

For the above three reasons, I definitely put my hands on both feet suggest you turn off the "circular log" feature.

According to one, my own lessons and experience;

Based on Microsoft's official description of the Exchange database.

For specific reasons, please look at the following content, which is based on Microsoft Official information and your own experience of managing Exchange Server, for your reference, to get a better understanding of the storage system of Exchange Server and the role of each part.

One, is service and ESE hierarchy relationships

The IS service must know well that it is one of the important services in the Exchange server that controls the request for storage operations on the MS (Mail Store) and PF (public Folder), and the Exchange Server is non-existent if the service is not started. We also know that the storage of the Exchange server is actually managed by the database engine called ESE. This ESE engine is developed by Microsoft specifically for the preservation of non relational data, and is currently widely used in many Microsoft products, such as AD databases, DHCP, WINS, SRS, and so on.

Exchange databases are made up of EDB files, STM files, and log files. In these files, Microsoft uses the "B + tree" internal data structure. One of the tasks of the ESE engine is to translate these requests into read and write access to internal data structures when the IS service requests access to the database. The "B + Tree" is characterized by the ability to provide fast access to the data stored on the hard disk. The main reason why Microsoft uses the "B + Tree" as the background structure of ESE is to improve I/O performance when accessing data as much as possible. Of course, these structures are transparent to the Exchange store.

In addition, as a database system, ESE has the responsibility to provide support for transaction-level operations and to maintain database integrity and consistency. For a database system, when we refer to a transaction, we typically use acid to describe the characteristics of the transaction:

A-atomic (Atomic): The transaction must be either full or full, or all will be successfully updated, or none be updated.

C-consistent (Consistent): A successfully committed transaction must put the database in a consistent state.

I-isolated (orphaned): All uncommitted changes must be able to be independent of other transactions.

D-durable (persistent): When a transaction is committed, changes must be stored on stable media to prevent database inconsistencies caused by system failures. (This point is very important!)

Atomic this word, I look up the dictionary is "Atomic, atomic energy, very micro" explanation, as if this translation is not quite right, feeling interpreted as "absolute" comparative understood.