Before changes are actually made to an Exchange database file, Exchange writes the changes to a transaction log file. After a change has been safely logged, it can then be written to the database file. It is common for changes to become available to end users just after the changes have been secured to the transaction log, but before they have been written to the database file.
- Exchange employs a sophisticated internal memory management system that is tuned for high performance. Physically writing out changes to the database file is a low-priority task during normal operation.
- Exchange can efficiently manage caching of more than a gigabyte of database pages. This cache includes pages read from the database to fulfill client requests, as well as changed pages that will eventually be written back to the database file.
- If a database suddenly stops, cached changes are not lost just because the memory cache was destroyed. On restart of the database, Exchange scans the log files, and reconstructs and applies any changes not yet written to the database file. This process is called replaying log files. The database is structured so that Exchange can determine whether any operation in any log file has already been applied to the database, needs to be applied to the database, or does not belong to the database.
- Rather than write all log information to a single large file, Exchange uses a series of log files, each exactly five megabytes in size. When a log file is full, Exchange closes it and renames it with a sequence number.
- The first log filled ends with the name Enn00001.log. The nn refers to a two-digit number known as the base name or log prefix
- An Exchange Enterprise 2003 server can have up to four storage groups, and the log files for each storage group are distinguished by file names with numbered prefixes (for example, E00, E01, E02, or E03).
- The log file currently open for a storage group is simply named Enn.log—it does not have a sequence number until it has been filled and closed
- The checkpoint file (Enn.chk) tracks how far Exchange has progressed in writing logged information to the database files. Typically, on a busy database, the checkpoint lags three or four log files behind the currently open log.
- There is a checkpoint file for each log stream and a separate log stream for each storage group. Within a single storage group, all the databases share a single log stream. Thus, a single log file often contains operations for multiple databases
- The checkpoint wraps three or four log files behind the currently open log, based on this information if you think the log file size is limited to 5meg, Exchange 2003 will write the data on to mail store when it reached 20Meg.
Do not forget the SG (storage Group) has all the logs for all mail stores.Log files are numbered hexadecimally, so the log file after E0000009.log is E000000A.log, not E000010.log. You can convert log file sequence numbers to their decimal values using the Windows Calc.exe application in Scientific mode. To do this, run Calc, and then on the View menu, click Scientific.
You can also see the decimal sequence number for a given log file by examining its header with Eseutil.exe. The first 4-KB page of each log file contains header information that describes and identifies the log file and the databases it belongs to. The command Eseutil /ml [log filename] displays a header like the following:
Base name: e00
Log file: e00.log
lGeneration: 11 (0xB)
creation time: 12/30/2002 05:07:12
prev gen time: 12/27/2002 13:38:14
Format LGVersion: (7.3704.5)
Engine LGVersion: (7.3704.5)
Now all you need to do drill down to Bin directory from DOS, and open the logs directory from windows explorer. Place both windows side by side just like I did here.
E:\Program Files\Exchsrvr\bin>eseutil /ml
Drag one of the log file from left window into Command prompt, and hit enter