How to Run Eseutil /P (Repair) in Different Scenarios
The Eseutil syntax and behaviors described in this section apply to Exchange Server 2003 Service Pack 2 (SP2), and give instructions for running the Eseutil repair on your database. The Eseutil repair mode corrects corrupted or damaged databases at the page and table levels, but not at the application level. A repair may complete successfully, leaving all database tables consistent, but with the database so severely damaged that it cannot be mounted. For more information about the Eseutil repair mode, see Eseutil /P Repair Mode.
Before you begin
Consider the following points before running the Eseutil repair mode on your database:
There must be sufficient disk space on the local logical drive for the temporary repair database. Keeping 20 percent of the size of the database files being repaired is suggested, although the size of the temporary file will vary widely depending on the nature of the repairs made. If sufficient space is unavailable, you may redirect temporary files to a different drive, as described below.
The streaming database (.stm file) must be in the same folder as the Messaging Application Programming Interface (MAPI) database (.edb file), or you must set a command line switch to identify the path for the streaming database, as described below.
Procedure
To run Eseutil /P
The basic command line syntax for repairing a database with Eseutil is:
ESEUTIL /P database_filename.edbNote
With Exchange Server 5.5, you need to run /V to see the verbose logging that is default with Exchange 2000 Server and later versions.
You may encounter these scenarios when running Eseutil repair against your database:
Database and streaming files don't match
Streaming file is missing
Database and Streaming Files Don’t Match
Some hard crashes may leave the database and streaming databases out of synch with each other, or you may have obtained a streaming database that is out of date with the database file. By default, repair will check for this problem at the beginning, and exit to give you a chance to obtain the correct file if it is available.
You can force repair to continue past this problem, but if the streaming file is one that does not actually belong with the database, this will not salvage data from it. Instead, all data will be deleted from the streaming file. Force a mismatch to be ignored only when you are very confident that the streaming and database files belong together, and that they are close to being in synch with each other.
The streaming database is composed entirely of raw user data. All logical structure and ownership information about the data is in the MAPI database (.edb file). All data in the .stm file that does not match the pointers in the .edb file will be lost during a repair.
Follow these steps for running Eseutil /P to ignore a streaming file mismatch:
To ignore streaming file mismatch
To ignore a streaming file mismatch, add the /I switch to the Eseutil command line. For example:
ESEUTIL /P priv1.edb /I
Streaming File is Missing
If the streaming database has been destroyed, or is missing, you can still successfully complete a repair, but with the loss of all data in that file. If the majority of your users are MAPI clients (Microsoft® Office Outlook® users), the data loss involved may be negligible. If most users connect via Post Office Protocol version 3 (POP3) or Internet Message Access Protocol version 4 (IMAP4), the data loss is likely to be catastrophic.
Follow this step to run Eseutil /P when a database streaming file is missing or when repair is unable to finish with the current streaming file:
To create a new streaming file
To create a new streaming file, use the /CREATESTM switch. For example:
ESEUTIL /P PRIV1.EDB /CREATESTM
Post-Repair Considerations
Remember the following points after you have run Eseutil /P to repair your database:
Perform a full backup of the database as soon as possible after a repair. Repair invalidates previous backups. This does not mean that previous backups cannot be restored or are completely worthless. It means that repair makes it impossible to completely roll the database forward from a previous backup. If you restore a previous backup, transaction log file replay will end at the point at which the repair was done. Any changes to the database subsequent to the repair cannot be put back into a restored database. Therefore it is critical that you perform a full backup of the database as soon as possible after a repair.
Remember that you must run defrag (Esetuil /D) and ISInteg -fix to finish repair. Only if you intend to use the repaired database for salvage and then discard it can you skip these extra steps. Skipping them means that you may salvage less data than if you completed them, but it can also mean saving several hours of recovery time.
Important
You must perform a full backup of the database, run defrag, and run ISInteg before placing a repaired database back in production. Microsoft IT's best practice is to move a mailbox as soon as it is feasible rather than to leave a repaired database indefinitely in production. For more information, see Eseutil /P Repair Mode.
Command line reference
This is the command line reference that can be seen by typing Eseutil ./? at the command prompt in the Exchsrvr\Bin folder, and the selecting P for repair.
REPAIR:
DESCRIPTION: Repairs a corrupted or damaged database.
SYNTAX: ESEUTIL /p <database name> [options]
PARAMETERS: <database name> - filename of database to repair
OPTIONS: zero or more of the following switches, separated by a space:
/s<file> - set streaming file name (default: NONE)
/t<db> - set temp. database name
(default: TEMPREPAIR*.EDB)
/f<name> - set prefix to use for name of report files
(default: <database>.integ.raw)
/i - bypass the database and streaming file mismatch error
/g - run integrity check before repairing
/createstm - create empty streaming file if the file is missing
/8 - set 8k database page size (default: auto-detected)
/o - suppress logo
NOTES: 1) Repair does not run database recovery. If a database
is in a "Dirty Shutdown" state it is strongly
recommended that before proceeding with repair,
recovery is first run to properly complete database
operations for the previous shutdown.
2) The /i option ignores the signature mismatch error in
the check phase if the database and streaming file do
not match each other. The database and streaming file
will receive new signatures in the repair phase. Without
using this option, repair will terminate immediately
once the database and streaming file mismatch error occur
3) The /g option pauses the utility for user input before
repair is performed if corruption is detected. This optio
overrides /createstm and /o options.
4) The /createstm option is irreversible. Once you
start the repair process a new streaming file will
be created. Any streaming file that existed before
the repair will no longer work with this database.
For More Information
For more information, see the following topics in the Exchange Server Database Utility Guide: