Transaction logs are very important and fundamental to the proper operation of an Exchange server. The way Exchange eventually 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's something that needs to be branded across the forehead of every administrator.

The details of the messages users work with do not appear in the databases until they have been committed, so the only place the data exists is in memory and the transaction logs. If a system failure occurs, the memory cache and version store are rendered useless and the transaction logs form the only repository that can be used to recover data. It's important to underline and understand this situation. Too many Exchange servers have experienced disk failures in the past three years only for the system administrator to find that they had lost data because the transaction logs weren't protected. The vast majority of the problems are related to hardware or administrative errors (like not taking successful backups), but there have certainly been some bugs that caused problems for the Store.

Every time the Store service starts up, the ESE engine automatically consults the databases to see whether they are consistent. A flag in the database header is...