In the default soft recovery scenario, an external event unexpectedly stops an Exchange database, but the database and log files remain intact and in place. When the database is mounted again, Exchange reads the checkpoint file and begins to replay the transaction log that is listed as the checkpoint log. If no checkpoint file exists, replay begins with the oldest log file available in the transaction log folder for the storage group.
Exchange writes to the database files completed transactions found in the log file that have not already been written and reverses any incomplete transactions. Exchange never begins writing a transaction into the database files until all the operations composing it have been secured to the log files. You do not need to physically undo or back out a transaction in the database if all uncommitted transaction logs present at the time of the unexpected stop are present when replay begins.
If you remove any required transaction logs from the replay sequence, Exchange fails soft recovery immediately. If needed transaction logs are missing, you must either perform recovery with an older, restored copy of the database (one that does not require those logs), or you must repair the database with the Exchange Server Database Utilities (Eseutil.exe) tool.
In most cases, the best way to run soft recovery is to mount any database in a storage group. Because all databases in a storage group share a single stream of log files, soft recovery occurs at the level of the entire storage group and not at the level of the individual database.
In some special circumstances, there are advantages to running soft recovery using Eseutil.exe. The most common scenarios are:
-
You want to recover a storage group that has a missing database.
-
You want to recover an individual database "out of place" without affecting other databases or the storage group's log files.
The complete syntax for the Eseutil.exe soft recovery function, listing all possible switches, is:
ESEUTIL /r enn /L[path to log files] /s[path to checkpoint file] /d[path to database file] /i
Example: ESEUTIL /r e01 /Lf:\mdbdata /sc:\exchsrvr\mdbdata /dg:\mdbdata /i
Note: |
---|
Eseutil.exe command line parameters are not case sensitive; they are mixed in case as shown above to avoid confusion between the "L" and "I" characters.
|
The above example shows the recovery of the databases for a storage group in which the log file prefix is E01, the log files reside in f:\mdbdata, the checkpoint file resides in c:\exchsrvr\mdbdata, the database and streaming files reside in g:\mdbdata, and missing databases are ignored (because of the /i switch at the end of the command).
The minimum Eseutil.exe command line needed to run soft recovery is:
This command works only if run from a prompt set to the transaction logs directory. You should also be aware of the following when using Eseutil.exe to run soft recovery:
-
If you do not specify any file paths on the command line, Eseutil.exe uses your current command prompt directory as the default for both log files and the checkpoint file.
-
Database files do not have to be in the log file path. The log files record the database paths, and therefore Eseutil.exe discovers all database paths by reading the log files. Use the /D switch to override the paths stored in the log files only when you are sure the paths in the log files are incorrect.
-
If the checkpoint file is not present in the same path as the transaction logs, all log files are scanned during replay, rather than starting replay from the checkpoint log. You can copy an existing checkpoint file temporarily to the log file path. After soft recovery is complete, Exchange no longer uses this copy of the checkpoint file in normal database operation.
If the information in the checkpoint file is incorrect, soft recovery fails but does not harm the database. You can try recovery again after removing the checkpoint file or finding the correct one. A checkpoint file is not essential to successful recovery, but it can save significant time if you have a large number of log files.
If you want to begin recovery when a database is missing from the storage group, you can use the command:
The /i switch means ignore missing databases. If you use this switch and then mount the missing database, Exchange prompts you to create a new database. If you intend to restore the old database at some point, you will not be able to replay the new data into it. You now have two separate versions of the same logical database.
This scenario, where one database in the storage group has been replaced by an empty database, is one in which the recovery storage group can help. You can mount the extra database in the recovery storage group, and use ExMerge to add the contents of one database to the other.
If you want to begin recovery "out of place" to recover a single database without affecting other databases in the storage group, you should create a new, empty folder and move the database files that you want to recover, the transaction logs that you want to replay, and a checkpoint file (if desired) into this path. This path must not contain other database files.
Once you have isolated your databases and logs together into a folder by themselves, run the following command from that folder:
By using the /d switch with no path designation, you override the database path set in the log files. In addition, because no other databases are available in this folder, you hide the other databases on the server from this particular recovery process.
If you do not use the /d parameter correctly, the recovery process can affect other databases on the server. Even in the worst case, the recovery process will not damage other databases. However, recovery may fail on the database that you are working with. This recovery operation may even impact future log file replay capabilities against other databases.
Note: |
---|
The likelihood of errors increases as the command line becomes more complex. As a general rule, then, minimize the specified path information on the command line when using Eseutil.exe. In this case, change to the directory where the files are located and include the \exchsrvr\bin directory in your system path.
|
To run soft recovery, the last log file in the replay sequence must be named Enn.log. If the final log file has already been closed and numbered, you must rename the log before soft recovery will succeed. This requirement does not mean that, where the current Enn.log file has been damaged or destroyed, you can ignore it and rename the previous log in the sequence Enn.log. In Exchange 2000, the Logs Required value in the database header lists the minimum sequence of logs required for recovery, starting from the checkpoint log and continuing to the current log. In earlier versions of Exchange, although no Logs Required value existed to enforce the presence of required logs, recovery still failed if the last log needed was not found. The only difference between Exchange 2000 and later versions was that recovery would fail at the end of log replay instead of at the beginning.