Eseutil /R Recovery Mode
Tópico modificado em: 2006-06-09
Recovery refers to the process of playing transaction log files into a database. There are two kinds of recovery:
- Hard recovery: A transaction log replay process that occurs after restoring a database from an online backup.
- Soft recovery: A transaction log replay process that occurs when a database is re-mounted after an unexpected stop, or when transaction logs are replayed into an offline file backup copy of a database.
For more information about hard and soft recoveries, see "Transaction Log File Replay: Soft Recovery and Hard Recovery in Exchange Server 2003" (https://go.microsoft.com/fwlink/?linkid=68147).
For more information about instructions for running Eseutil in recovery mode, see How to Run Eseutil /R in Recovery Mode.
Hard Recovery
Hard recovery occurs when transaction log files must be replayed into a restored online backup. In all other recovery scenarios, soft recovery is done. Hard recovery can be done with Eseutil by using the Restore mode (/C).
Soft Recovery
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 completed transactions to the database files 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.
Importante
A fundamental assumption of the soft recovery process is that no database or log files have been moved, deleted, or destroyed by the failure—or by the administrator after the failure.
Version Differences
Eseutil is always being improved, and added to from version to version. There are currently three major versions of Eseutil /R for each of the 3 major exchange versions as follows:
- Exchange Server version 5.5
- Exchange 2000 Server
- Exchange Server 2003
Exchange Server 5.5
The command line syntax for soft recovery with Eseutil in Microsoft® Exchange 2000 Server and Microsoft® Exchange Server 2003 is different from that used in Exchange 5.5. The rules and best practices for performing manual soft recovery with Eseutil have also changed.
In Exchange 5.5, there is almost never a good reason to perform soft recovery with Eseutil. Each time the Information Store starts, soft recovery is run automatically, and correctly. In Exchange 5.5, the Eseutil soft recovery function was intended mostly for test environments where you might wish to recover a database on a server that did not have Exchange installed.
There is a major risk in running Eseutil /R in Exchange 5.5: After restoring an online backup, running soft recovery instead will usually corrupt the database. An online backup needs hard recovery, not soft recovery.
Only if the following two conditions are both met is it safe to run soft recovery instead of hard recovery in Exchange 5.5 and previous versions:
- The database paths have not changed since the backup was done.
- The .pat files from the online backup set are exactly 8 K in size (meaning, that they are composed of only two header pages, and have no actual database pages in them).
In all other circumstances, running soft recovery instead of hard recovery will corrupt the database in proportion to the size of the .pat files.
Dica
If you divide the byte size of a .pat file by 4096, and subtract two, that is the number of logically corrupt pages that will be in the database after improperly running soft recovery.
Exchange 2000 Server
In Exchange 2000, safeguards were implemented that always prevent soft recovery from running when hard recovery is needed.
There is another risk in running soft recovery with Eseutil. This risk still exists in Exchange 2000 or Exchange 2003: If you improperly specify paths to log files, to the checkpoint file or to database files, recovery may alter the database or log files and prevent recovery from being done again.
If existing transaction log files are not found by Eseutil when it tries to run recovery, it will create a new transaction log file, and try to attach the database to it. If the database is Inconsistent or in Dirty Shutdown state, the database will not be made startable. If the database is in a Consistent state, it will be attached and then detached from the new log file.
In either case, you risk making changes to the database or adding log files to the server that will result in the database becoming unstartable or that will confuse further recovery troubleshooting.
Dica
Just because recovery with Eseutil reports success does not mean that the database recovered is in a mountable state. Recovery succeeds whenever all available transaction log data that is currently available has been applied to the database files. Recovery success says nothing about whether the available data was sufficient to restore the databases to consistency.
In Exchange 5.5, you were almost always better off placing files in appropriate locations and then starting the Information Store to accomplish recovery. In Exchange 2003, there are two improvements to the Eseutil recovery functionality that provide important advantages over mounting a database to run recovery on it:
Eseutil can force recovery to complete even if there is a missing database. This capability is also available in Exchange 2000.
If a storage group is unexpectedly stopped, all databases running at the time will be Inconsistent in a Dirty Shutdown state. Suppose that the reason the storage group stopped was that a database drive suddenly failed, and the drive is inaccessible. In this case, you are missing one of the databases.
If you run recovery while the database is missing, it is possible that you will alter the state of the transaction logs so that if the drive becomes accessible again, recovery will not complete successfully with that one database.
Dica
If you restore the database from backup, recovery will be able to complete successfully—this scenario only applies to recovering a database that was attached to the current log at the time of the sudden stop.
If you know that the lost database will not be recovered, you can recover the rest of the databases in the storage group without first restoring the missing database from backup by using the Eseutil /I (ignore) switch.
Before using this switch to run recovery on the rest of the storage group, you should first make a backup of all transaction log files, including the current log (Enn.log). By keeping a copy of the current log and all the other logs, you will still be able to recover the missing database if it unexpectedly becomes available. Once you recover the rest of the databases, and thus write more information into Enn.log, you may not be able to recover the missing database using that log file.
Exchange Server 2003
Eseutil recovery can recover a database that has been moved to a different path location. This capability is available only in Exchange 2003.
Hard recovery has always been able to finish successfully, even if Exchange databases have been moved to different path locations since a backup was done. But until Exchange 2003, soft recovery could only work if the database files were in the same drive path as that defined in the transaction log files to be replayed.
In Exchange 2003, the /D switch was added to Recovery mode to allow override of the database path hard coded in the transaction log files. This new capability is very useful when restoring offline copies of databases to Recovery Storage Groups, or when recovering a “missing” database as described in the scenario above.
You can now copy a database and a group of transaction logs into any folder you desire, and successfully run soft recovery. Once the database is consistent, you can then move it to any other path desired, and attach it to a different log stream.
For More Information
For more information, see the following topics in the Exchange Server Database Utility Guide: