Microsoft Exchange Server 2003

Transaction logs are very important and are fundamental to the proper operation of an Exchange server. The way Exchange commits transactions to the database on an asynchronous basis means that it is entirely possible for users to read and write messages entirely in memory. You can receive and read a message without ever going near the database. This is the major implication of the write-ahead logging model used by Exchange, and it is something that every administrator needs to understand.
Messages do not appear in the databases until they have been committed, so until commitment the only place the data exists is in memory and the transaction logs. A system failure renders the memory cache and version useless, and the transaction logs then form the only repository that ESE can use to recover data. It is important to underline and understand this situation. Too many Exchange servers have experienced disk failures in the past, only for the system administrator to find out that the data had been lost because it was not adequately protected in the transaction logs.
Every time the Store service starts up, ESE automatically checks the databases to see whether they are consistent. A flag in the database header is set to "consistent" or "inconsistent," depending on whether the database was shut down cleanly and ESE managed to flush all the data in the cache to disk. The flag is always set to "inconsistent" when a database is active, implying that data exists in...