Article ID: 259851 - View products that this article applies to.
This article was previously published under Q259851
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:
(http://support.microsoft.com/kb/192185/ )How to defragment with the Eseutil utility (Eseutil.exe)
(http://support.microsoft.com/kb/182081/ )Description of the Isinteg utility
The Isinteg utility fixes the logical problems that may arise when you run a hard repair:
For more information about Exchange disaster recovery, click the following article number to view the article in the Microsoft Knowledge Base:
162353After 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:
(http://support.microsoft.com/kb/162353/ )Restoring an Exchange Directory
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:
(http://support.microsoft.com/kb/259688/ )How to use the Exmerge utility to extract data from a damaged private information store
To determine if a hard repair has been run against your database, dump the header by using the following command line (the repair count will be zero if the databases have not been repaired):
eseutil /mh x:\exchsrvr\mdbdata\priv.edb |moreThe following is a sample of a Priv.edb header:
eseutil /mh x:\exchsrvr\mdbdata\pub.edb |more
Microsoft(R) Windows NT(TM) Server Database Utilities
Copyright (C) Microsoft Corporation 1991-1999. All Rights Reserved.
Initiating FILE DUMP mode...
Format ulMagic: 0x89abcdef
Engine ulMagic: 0x89abcdef
Format ulVersion: 0x620,2
Engine ulVersion: 0x620,2
DB Signature: Create time:4/5/2000 17:48:52 Rand:769046 Computer:
Last Objid: 184
Scrub Dbtime: 0
Scrub Date: 00/00/1900 00:00:00
Repair Count: 1
Repair Date: 2/20/2000 10:48:50
Article ID: 259851 - Last Review: October 28, 2006 - Revision: 6.2