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:

1. Eseutil is run in /P mode to perform a database page-level and table-level repair

2. Eseutil is run in /D mode to fully rebuild indexes and defragment the database

3. ISInteg is then run to repair the database at the application level

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.

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:

For More Information

For more information, see the following topics in the Exchange Server Database Utility Guide:

• Eseutil /D Defragmentation Mode

• Eseutil /C Restore Mode

• Eseutil /R Recovery Mode

• Eseutil /G Integrity Mode

• Eseutil /M File Dump Mode

• Eseutil /K Checksum Mode

• Eseutil /Y Copy File Mode

• Database Recovery Strategies

• Reference for Common Eseutil Errors