Introduction: Consistent and In–Consistent Exchange® Database
Exchange Server database gets shut down in two ways: Clean Shut down (DB is consistent) and Dirty Shut down (DB is in-consistent). If the database is inconsistent, nothing can be processed against it until it is brought to consistent state.
If database is in dirty shut down state, it means that the log files have outstanding transactions to be committed to the database. Next time when Exchange Server starts up, it will look out for missing data in the database and will check the transaction log for it. If the data is found, it will be written to database and if not, the DB will not be started.
On the other hand if the database is in clean shut down state, it means all transactions in log file have been written to the database. Nevertheless, log files prove very helpful in situations when an older version of database has to be restored.
What is Transaction Log File?
Transaction + Logging = Transaction Log File
A transaction is simply a set of operations that are processed against the database. It can be moving data from one folder to another, deletion of an item, adding an email to email folder etc. All these transactions get logged in a file that is known as Transaction Log Files.
When the transactions pass following set of rules, they are written to the database:
How To Test State of Database Using ESEutil
To check if Exchange Server database is in Clean or dirty shut down state, /mh switch of ESEutil can be used. The standard syntax for it is:
For Example:
In this segment, we will discuss the process to restore Exchange 2010 database with ESEutil that is inconsistent in state. Meanwhile, the recovery modes shared here does not promise recovery if database is corrupt. It is meant for situations where DB is in dirty shut down state and there are issues in mounting database on Server or there are errors 550, 528 etc.
If Exchange Server database shuts down unexpectedly, the database and log files will remain intact. When the DB is mounted to Server again, Exchange Server will examine the Checkpoint file to see which transactions in log file are to be written to database. If no pending transaction is found, it replays log file from starting. This process of replaying log files after Exchange Server stops without warning is called Soft Recovery of database.
In this process, Exchange automatically writes uncommitted transaction to the database. Meanwhile, it should be noticed that a transaction will not be written to DB until all operations making a transaction are not saved in log file (the Atomic property of transaction shared above).
If the log file has uncommitted transactions available at the time of database shutdown, replay will start. Here, the point worth noticing is once the operations are secured in log file, they cannot be deleted, moved, or destroyed by failure. If any of the log file is missing from the sequence, the soft recovery process will fail. This is the reason it is suggested not to delete any log file ever.
By default, soft recovery is performed by Exchange Server automatically. Meanwhile, soft recovery of database can be run through /r switch of ESEutil. The standard syntax for it is:
Hard Recovery is again the process of replaying transaction logs but not on the database on production Server but on the database that is being restored from online backup. This recovery also gets automatically processed when "Last Backup Set" option is enabled at the time of backup restoration. As we mentioned that it is a log replay process but still it differs from soft recovery in following aspects:
Using this method will free–up the administrator from following tasks:
Database file of Exchange Server when restored from online backup are restored to their original location and the process of restoration take place by overwriting the database. If there is probability that you might need the data before restoration in future, then take a backup of the DB files at an alternate location. For example: Say hard recovery failed because of any reason, then in that case you have option to repair the database if necessary to salvage its data.
As mentioned above, this type of recovery take place automatically when "Last Backup Set" is enabled while restoration of online backup. However, to manually process hard recovery, ESEutil can be used.
When backup is restored, a restore.env file gets created in the Temporary folder of the system. This file is used while recovery, i.e. for replaying transaction logs against restored database.
To replay log file, the standard syntax (hard recovery) is:
Note: In this case, only those log files will be replayed that are instructed by restore.env file.
Transaction Log Replay Facts
FACT #1: Log file of a database cannot be replayed against another database.
FACT #2: If a database is defragmented or repaired, log files associated with DB earlier cannot be replayed against it.
FACT #3: Checkpoint file defines the point from where log file has to be replayed.
FACT #4: If any log file is missing from the sequence, replay process will fail.
Conclusion: The methods shared in this segment to restore Exchange 2010 database with ESEutil will help to bring an inconsistent database into consistent state. If these processes fail to bring DB into functional state, then the suggestion is to repair database using /p ESEutil switch or you can recover EDB into PST or another Server using third party solution.
For more info: https://www.edb.2pst.net/