SUMMARY
A hard repair occurs when you run an
eseutil /p or
edbutil /d /r command against an Exchange Server database file, such as the
Priv.edb, Pub.edb, or Dir.edb database. The repair goes through the database
and checks and repairs critical structures inside the database (such as system
tables, attachment tables, and so on) and checks for damaged pages in the
databases.
If the repair encounters a page that is damaged (for
example, an invalid checksum caused by a modification to the page that was not
preformed by Jet) it deletes the page (-1018). When this happens, critical data
may be lost after the repair finishes. This data may be part of an e-mail
message, a calendar appointment, a note, an attachment, or in the worst-case
scenario, part of a system table.
If that system table is the
attachment table, every user on the server may lose the attachments to their
messages. This is only one possible scenario, but if there are damaged pages in
the database, data will be lost following a hard repair.
Important It is always best to restore from a backup whenever
possible.
If you restore from a backup, you ensure that you have a
good, clean, stable, database that will start and run on your server. In almost
every circumstance, it is faster and more reliable to restore from a backup
than to perform a hard repair on the database. This is because the repair runs
at approximately 4 to 6 gigabytes (GB) per hour, and you must run the Isinteg
process after the repair, which runs at approximately 3 to 6 GB per hour.
(These rates are average; performance may vary depending on how many passes the
repair has to make on your database and the speed of the hardware.)
For example, if you use the fastest possible hardware setup, a 50-GB database
requires approximately 8 hours for repair and approximately 8 hours for the
Isinteg process, for a total of 16 hours. If you use a typical Wide
SCSI-connected digital linear tape (DLT) 35/70, which averages around 3
megabytes (MB) per second for restoration, the same database needs
approximately 5 hours for restoration. That is a time savings of 11 hours.
Extremely high speed "snapshot" type backup systems, such as the system from
EMC Corporation, can restore a database of this size in a matter of
minutes.
If you have no backup, and no other option but to run a hard
repair on your database, follow these steps:
- Run a hard repair on the database by using Eseutil /p or Eseutil /d /r.
- Defragment the database by using Eseutil /d. Offline defragmentation creates a new physical database structure and moves the existing data to that structure.
- Check the consistency of the database by using Isinteg -fix. You may need to run Isinteg several times until the summary report returns no errors.
For more information, click the following article number to view the article in the Microsoft Knowledge Base:
192185
How to defragment with the Eseutil utility (Eseutil.exe)
182081 Description of the Isinteg utility
The Isinteg utility fixes the logical problems that may arise when
you run a hard repair:
- For the Exchange Server 4.0 and 5.0 private information
store, run the following command:
- For the Exchange Server 4.0 and 5.0 public information
store, run the following command:
- For the Exchange Server 5.5 private information store, run
the following command:
isinteg -pri -fix -test alltests
- For the Exchange Server 5.5 public information store, run
the following command:
isinteg -pub -fix -test alltests
Note You cannot run the Isinteg -fix command against the Dir.edb database. Additionally, we recommend that you do not run a hard repaired directory in a production environment.
For more information about Exchange disaster recovery, click the following article number to view the article in the Microsoft Knowledge Base:
162353
Restoring an Exchange Directory
After you run the
eseutil /p or
edbutil /d /r command on the Priv.edb or Pub.edb databases, the databases may
exhibit the following symptoms:
- The information store either will not stop or stops
responding.
- The information store stops accepting mail from the message
transfer agent (MTA).
- E-mail remains in the Outboxes of the users.
- The Store.exe program runs with very high CPU use with no
load on the server.
- The Store.exe program generates an access violation if
there is a heavy load.
- Users cannot open e-mail attachments or e-mail
messages.
After you run a hard repair on a database that has extensive
damage, it is not fit for production use until you have also performed the offline defrag followed by isinteg. Only run a hard repair on your
database as a last resort; if possible, always restore from a backup.
If Isinteg is run multiple times and does not correct the database corruption, you must use the Exmerge utility to extract data from one database and place it in another database:
259688 How to use the Exmerge utility to extract data from a damaged private information store