Many a times, Exchange Server is addressed as a transaction-based emailing system. Transaction is simply set of operations that are performed against the database which can be inserting or deleting an item or updating the database by following set of rules:
A transaction will be committed to Extensible Storage Engine (ESE) database only when it passes the durability test. Moreover, a transaction must reach log file on disk by its transition from memory. Consider an example: An email from Inbox folder has to be moved into folder named "New". In this case, following logical operations will be processed by Exchange Server:
Now, this three step procedure of moving an email from folder to another will be counted as one transaction, In case any of the operations fail, no transaction will be logged in the memory or to the log file. This reflects the "Atomic" character of transaction that says either all operations will occur or none will occur.
An Exchange Server administrator would agree to the fact that transaction logs are equally important as the database files are as far as DB recovery is concerned. This is because log files manifest operations that take place up to second. So basically, transaction logs carries data that even database might not have and thus they play an important role in recovery of Exchange database at times of failures. Without log files, DB would be inconsistent and most probably unusable.
Extensible Storage Engine (ESE) uses Write-Head logging technology that ascertains DB protection against power failure, hard disk, or system failure. This first writes the transactions to log files on hard disk and then to the database on Server. The up-dations done into the database page are cached into the memory but they are not instantly written to the disk. Every transaction in log file is added sequentially which makes the input/output operations of transaction log quick.
The basic task of log files is to keep a record of volatile data in memory that has not been added to the database (.edb/.stm) file on disk. In case the system crashes and as long as the DB is available in healthy state, there is positive chance to recover data till last committed transaction. This is the reason why protection of log files hold importance and they should be saved on an alternate disk (if case DB files are affected, the log files remain safe).
Version Store and Checkpoint File
When a transaction is created and till the time it is written to database, there are number of processes that take place. Meanwhile, which transaction is has made its way out to DB or which one is outstanding, its track is kept by:
Version Store: Transactions follow a two-step procedure from the while it is created and committed. This is to ensure that changes done to the database are recorded before they are written to it. In case any transaction is terminated before completion, all related updates to the transaction are rolled back. If changes are done into any page of the database, it is first registered into transaction log buffer. A Version Store keeps a track of operations that are pending to be written into the database in memory.
Checkpoint File: Version Store gives information about outstanding transactions cached in memory and the same information on disk is provided by Checkpoint file. Its main aim is to provide an idea about what transactions are being complete and had made a way to database. It tells the ESE database to start and end point of recovery process which makes the entire process a little less time –consuming.
There are two ways in which a database on Server is shut down: Dirty Shutdown and Clean Shutdown. Depending upon both these factors, the database is categorized as being "consistent" or "Inconsistent".
Defining the Terms:
Tip:
To verify the state of database, ESEutil /mh command can be used:
Example:
Before moving on, it is important to understand two major, different, and sometimes similar considered terms: Restore and Recovery.
Restore means putting back the database and log files to their original place on Server while Recovery means replaying log files into restored database.
There are two ways in which Exchange Server performs recovery of Exchange database:
Soft Recovery: The process of replaying transaction log files when a database is re-mounted on Server after facing an unanticipated stop. In this case, Exchange Server automatically performs soft recovery to commit any pending transaction to log file by reading checkpoint file.
Then, this recovery is performed against offline copy of database. Here, the recovery has to be processed manually using ESEutil tool. For manual replay of log files, the syntax is:
Hard Recovery: This process includes replaying log files after restoring database from online backup. It can be processed automatically when "Last Backup Set" check box is enabled while backup restoration. It is similar to soft recovery but is different from it in the aspect that instead of Checkpoint file, Restore.env file can be used to replay log files.
Meanwhile, if the "Last Backup Set" option is not enabled while restoration, it can be manually performed using ESEutil. To start up, restore online backup using a reliable source (Example: Windows Server Backup). When this will be done, a Restore.env file will be created in Temporary folder of system.
To replay Log files in restore.env file against Exchange EDB file (restored DB) file, hard recovery can be performed using following syntax:
Meanwhile, it is important to know that adding any additional log file for replay will not do any good here. Only those log files will be replayed that are restored from backup and are available in restore.env file.
The recovery scenarios discussed above aims at bringing database from inconsistent to consistent state (the database is in healthy state; not corrupt). For performing soft or hard recovery, it is important that all log files are available in healthy state. There are two ways in which log files can affect recovery process:
In such scenarios, the recovery process might fail with following error messages:
| Error Number | JET Error | Error Description |
| Error -501 (0xfffffe0b) | JET_errLogFileCorrupt | Log File is Corrupt |
| Error -514 (0xfffffdfe) | JET_errBadLogVersion | Log file generated with different Exchange Server or edition |
| Error -515 (0xfffffdfd) | JET_errInvalidLogSequence | Any log file from the sequence is missing |
| Error -533 (0xfffffdeb) | JET_errCheckpointCorrupt | Checkpoint file is deleted or corrupt |
If log files are unavailable or missing, then database can be brought to consistent state or to functional state (even if corrupt) through repair process which can be executed through /p switch of ESEutil. The standard syntax that could be used to recover Exchange database without log file is »
Notification: Using this process to make database consistent might lead to data loss if ESEutil finds any page corrupt, broken links between the tables, or if any structure improvement calls for deletion of internal pages. This could end up with need to rebuild database using offline defragmentation and correct B-tree structure of database which obviously becomes a lengthy and complicated task with ESEutil.
An alternative to this process is opting for an EDB file recovery tool that just calls for database file availability (healthy/offline/corrupt state) to get consistent DB. Exchange Recovery software provides a GUI mode to recover database from EDB file to PST, EML, MSG file, and to another Exchange Server without dependency upon log files.
