Similar to previous versions of Microsoft Exchange Server, Exchange 2007 uses the Extensible Storage Engine (ESE) database. However, the ESE database was changed architecturally in Exchange 2007. One such change involves log sequence number limits. In this tip, Microsoft MVP Brien Posey explains some fault-tolerance feature updates to the ESE database in Exchange 2007 and how they can improve data loss prevention.
When Microsoft designed Exchange Server 2007, it continued to use the Extensible Storage Engine database. But the company did make some major architectural changes to the legacy database engine.
For example, the company eliminated the Streaming Database File and decreased the size of transaction logs from 5 MB to 1 MB. There were also lesser-known architectural changes, some of which were geared toward making the database less prone to failure.
One architectural change involves log sequence numbers. In Exchange Server 2003, the highest attainable log sequence number was FFFFF0, which means that Exchange can accommodate a maximum of 1,048,560 log sequence numbers. When this limit was put in place, a 1 million log file limit wasn't a big deal. Exchange 2003 log files are 5 MB in size, so the log file limit is reached every time the server accumulates 5 TB worth of data. When this happens, the server must be shut down so that the log files can be re-sequenced, starting at one.
Currently, this log file limit is really only an issue for very large organizations. It can take smaller organizations several years to accumulate 5 TB worth of transaction logs. Even so, this limit could potentially have been more disruptive in Exchange 2007 because Microsoft decided to decrease the log file size to 1 MB. If the 1,048,560 log file limit were still in place, then the server would have to be reset every time a database accumulated about a terabyte of data. Therefore, Microsoft increased the log file limit to 2,147,483,647 files.
This raises the question of why Microsoft chose to decrease the log file size in the first place. The reason has to do with data loss mitigation. The basic idea behind it is that if a log file is damaged, you will lose 1 MB of data instead of 5 MB.
Another new fault-tolerant feature is lost log resilience (LLR). In previous versions of Exchange Server, it was tricky to recover from crashes. For instance, if a crash resulted in lost log files, and those log files had not been committed to disk, you typically would either have to restore a backup and revert to a previous database state or perform an offline database repair before you could mount the database.
Lost log resilience is an Exchange 2007 feature that allows you to mount a database, even if the last few log files have been lost or damaged. You might lose some of the more recent log files, but not the others because of the way Exchange Server writes log file data. Exchange always writes transactions to memory first, then to the transaction logs and finally to the database. LLR delays the process of writing transactions to the database until a certain number of transaction logs have been created. To set the number of logs that can be lost during a failure, adjust the AutoDatabaseMountDial parameter following steps explained in this Microsoft article.
Although LLR is enabled by default on all mailbox servers, it's primarily designed to work with cluster continuous replication (CCR). In a CCR environment, it's possible to run into situations in which the primary node fails and the passive node has not yet received all of the latest transactions. LLR allows the passive database to be mounted automatically, as long as an excessive number of transactions have not been lost.
Note: LLR only runs on the active copy of the database, because the passive copy is kept as up-to-date as possible.
Another feature that balances the effectiveness of LLR is transaction log roll. Essentially, this feature monitors Exchange Server to find extended periods when no transactions occur. During this time, the transaction log roll feature closes out open transaction logs, and if enough idle time passes, will create empty transaction logs. That way, if a failure does occur, and the last few log files are lost, those lost logs may not contain any data if the failure occurred when there haven't been any transactions in a while.
About the author: Brien M. Posey, MCSE, is a five-time recipient of Microsoft's Most Valuable Professional award for his work with Exchange Server, Windows Server, Internet Information Services (IIS), and File Systems and Storage. 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 website at www.brienposey.com.
Do you have comments on this tip? Let us know.
Please let others know how useful this tip was via the rating scale below. Do you know a helpful Exchange Server, Microsoft Outlook or SharePoint tip, timesaver or workaround? Email the editors to talk about writing for SearchExchange.com.
