Eseutil /P Repair Mode
The Eseutil repair mode corrects database problems at the page and Extensible Storage Engine (ESE) table levels but not at the application level. After repairing a database using Eseutil, ISInteg should be run to repair the database at an application level. To understand what database page level, ESE table levels, and application levels mean, see Database Recovery Strategies. For more information about syntax and instructions for using Eseutil /P, see How to Run Eseutil /P (Repair) in Different Scenarios.
During repair, it may be necessary to discard rows from tables or even entire tables. After completing the ESE-level repairs, it is necessary to perform an application-level repair to correct problems that may now exist at the application level because of missing data. The Information Store Integrity (ISInteg) utility can be used to perform this Exchange application-level analysis and repair. The following example explains how Eseutil repair works.
For example, a table in the database stores messages for all mailboxes. A separate table is used for each user's Inbox folder. Suppose that a message is lost when using Eseutil to repair the message table. Eseutil will not correlate the message with the reference to it in each Inbox folder, because Eseutil does not understand the cross-table schema of the application. ISInteg is needed to compare the repaired message table with each Inbox folder, and to remove a lost message from the Inbox.
In short, Eseutil looks at each Exchange database page and table and ensures consistency and integrity within each table. ISInteg, recommended to be run after Eseutil, repairs a database at the application level and ensures the integrity of the relationships between tables.
Repairing databases involves the following three stages, in this order:
Eseutil is run in /P mode to perform a database page-level and table-level repair
Eseutil is run in /D mode to fully rebuild indexes and defragment the database
ISInteg is then run to repair the database at the application level
A successful repair does not necessarily mean that a database will always be useable. The loss of system metadata may leave a database unmountable or empty. When a database is not repairable, you can restore data from backup or create a new database.
Placing a Repaired Database Back Into Production
It is a judgment call whether to leave a repaired database permanently in production. The policy of many administrators is to use repaired databases only for data salvage. Administrators move mailboxes as soon as possible to another database, or merge the data from a repaired database into a known good database.
Both Eseutil and ISInteg generate detailed repair log files that list the errors found and corrected. For more information about causes and consequences of specific errors, you can search the Microsoft Knowledge Base and see the topic on Reference for Common Eseutil Errors. Information from these areas can help you decide whether you wish to accept the risks of leaving a repaired database in production.
Eseutil /P Best Practice
Use Eseutil /P when you cannot restore a database from backup or when you cannot fully roll transaction logs forward.
If you cannot roll forward transaction log files, a hybrid strategy is best to follow. You can restore a working version of the database from backup, repair the damaged database in the recovery storage group, and merge the two databases.
Microsoft recommends that you follow these best practices when repairing a database:
Do not allow a repaired database to remain in production for an extended period of time.
Do not use the Eseutil repair option when backup is available.
Do not use Eseutil repair mode to expunge a -1018 error. For more information about error -1018, see Microsoft Knowledge Base article 812531, "Support WebCast: Microsoft Exchange: Understanding and Resolving Error -1018" (https://go.microsoft.com/fwlink/?linkid=3052&kbid=812531).
Previous Exchange Versions
The table below explains how the Eseutil repair mode works in different versions of Exchange:
By default, detailed logging of the repair process is stored in a plain text file called database.integ.raw. This log will tell you exactly which tables were repaired and what problems required their repair.
It was necessary to specify verbose logging with the /V switch to see similar detail.
For More Information
For more information, see the following topics in the Exchange Server Database Utility Guide: