Exchange Server Transaction Logs

The Information Store (IS) and Directory form the core of Microsoft Exchange Server. Systems administrators expend a great deal of effort to protect these databases. Administrators use RAID 5 or RAID 0+1 disk configurations to protect data; perform frequent backups; and carefully plan the stores' location on their servers' available disk volumes. I applaud systems administrators who take these precautions—the IS and Directory need as much protection as possible. But administrators mustn't limit data protection for Exchange Server to the databases. The databases' transaction logs (the IS and Directory each have a set) need protection too.

The IS and Directory use a write-ahead transactional model to protect data. Before Exchange Server commits data to one of the stores, it writes the data to a log file. Exchange Server logs every IS and Directory transaction from every source. After a transaction occurs, Exchange Server records it in the current log and writes the modified database pages to a memory cache. When system load permits, Exchange Server commits the pages in the cache to the appropriate store.

Exchange Server manipulates database pages in the cache to adjust the order of transactions and optimize the process of committing transactions to the database. Page caching also improves performance: When a transaction uses an already-cached page, Exchange Server can update the page in memory rather than generating additional disk operations. You might not think transactions often reference cached pages, but when an inbox receives multiple messages over a short time, the first transaction caches inbox data and subsequent transactions access inbox data in memory.

Exchange Server maintains data integrity by writing every transaction to a log file; Exchange Server never commits a transaction to a database unless the transaction is complete. Before Exchange Server can commit a transaction, it must perform a series of operations. For example, when a new message arrives, the IS must locate the rows for recipient inboxes in the folders table and locate the table that contains the target inbox data, and update both tables. If the IS can't complete these steps (e.g., because a software or hardware failure occurs), it regards the transaction as incomplete and won't commit the transaction to the database. Because transaction logs are so important to Exchange Server's data integrity, you need to use RAID and backups to protect not only the IS and Directory, but also the IS and Directory transaction logs.

Understanding Transaction Logs
Exchange Server transaction logs are always 5MB. When the current transaction log file—edb.log—fills, Exchange Server renames the log edbxxxxx.log (the xxxxx portion of the name is a hexadecimal number starting with 00001) and creates a new edb.log file to accept transactions. (Microsoft calls each Exchange Server transaction log a generation.)

On servers with heavy traffic, Exchange Server can generate hundreds of transaction logs per day. You must select a location for these logs carefully. The disk you allocate to hold these files must contain enough space to store the transaction logs until Exchange Server removes them. Exchange Server deletes transaction logs whenever it completes a full backup. If the IS or Directory attempts to create a new transaction log when the transaction log disk has less than 10MB of available space, the IS or Directory shuts down. Exchange Server reserves an additional 10MB of space in two log files—res1.log and res2.log—to protect outstanding data if the logs exhaust the allocated disk space. Exchange Server uses the first 5MB of this disk space to write outstanding transactions to the res1.log file. If Exchange Server needs to write more than 5MB of transactions (which is possible on very large systems), it uses the res2.log file. After Exchange Server uses res1.log and res2.log, the files become typical log files with edb.log names. Exchange Server can't write more than 10MB of data to the reserve files; thus, you need to monitor free space carefully on transaction log disks.

Screen 1 shows a set of transaction logs. The edb00668.log file is the last log Exchange Server created before it created edb.log. Screen 1 shows that Exchange Server logged these two files at approximately the same time (11:54 a.m.), which indicates that the server was under a reasonably heavy load.

The header information inside a log file contains a hard-coded path to the log's database, a time stamp that shows when Exchange Server created the log, a unique database signature that prevents Exchange Server from replaying transactions to the wrong database, and the transaction log's data. You can use the ESEUTIL utility in Exchange Server 5.5 with Service Pack 1 (SP1) to dump a log file's header and view the header information. For example, you can type

C:\WINNT\SYSTEM32\ESEUTIL /ML <log_edb01969>

To make sure you have the updated version of ESEUTIL in the EXCHSRVR\BIN directory, select eseutil.exe and click File, Properties. If you have the updated version of ESEUTIL, your version number will be 5.5.2232.0. (The original version distributed with Exchange Server 5.5 is 5.5.1960.3.) If you need to replace the file in the EXCHSRVR\BIN directory, you can copy the correct version from the Exchange Server 5.5 SP1 CD-ROM.

When you view the transaction log dump, the checkpoint, date, time stamp, and database signature are easy to find. Other important information in the transaction log dump includes the path and filename of the database the log belongs to. Exchange Server uses the rest of the information to replay log transactions when necessary. For example, Figure 1 shows the log dump for one of my IS transaction logs. This file contains information about a public store and a private store.

   Previous  [1]  2  3  Next