Exchange database repair tool
Make a copy of the database files before you repair them. (cause you never know)
If you're not sure where your database files are, or what they are called, you can find out in Exchange System Manager by accessing the database properties. The Database page lists the paths and names.
Ensure you are prepared
Verify that you have sufficient disk space to do the repair. As a general rule of thumb, you should have the equivalent of 20% of the database size. If you don't have that much free space on the drive where the database files are, you can use command line switches to redirect the temporary files created during repair to a different drive.
*You will actually need 110% of your database size for the defrag later on, so move stuff to backup hard drives and use the temp file switches on command line
Run Eseutil in /P (repair) mode.
The easiest way to do this is to have both database files (.EDB and .STM) in the same directory (which they usually are). If they're in different places, you're going to have to point to the files on the command line.
Eseutil is located in the \exchsrvr\bin directory
Example:
eseutil /p c:\exchsrvr\mdbdata\db1.edb /sd:\exchsrvr\mdbdata\db1.stm /te:\temp.edb
This command line will repair DB1.EDB located on C: along with its matching .STM file located on D: and will put the temporary file on the E: drive.
If your streaming database file (.STM) is not matched to the database file (.EDB) or it has a problem that is blocking repair, you can add the /i switch to the repair command line.
The /i option ignores the signature mismatch error in the check phase. The database and streaming file will receive new signatures in the repair phase.
Repair can take a while-hours. When it finishes, it will leave you with a very detailed log file of what it did called .integ.raw.
Not quit finished yet, there are two more steps to complete.
Please see some more links in the conclusion for examples of the command line and a brief intro to the exchange utilities
Defrag the exchange database
Run Eseutil in /D (defragment) mode.
Repair may leave index and space allocation problems in the database. Along with compacting the physical size of the file, defragmentation rebuilds the indexes and space trees.
To defragment the database, you need space equivalent to 110% the size of the database.
As with repair, you can redirect the temporary file to a different drive if necessary, but this will take considerably longer.
Please see the microsoft link in conclusion for the real good info about this process, but unfortunately you need to read the whole article no skimming through, :-)
Your database is now restored, you need to move/backup all the transaction logs for your database otherwise it won't mount or run the integrity check.
Run Isinteg in -fix -test -alltests mode.
E.G. isinteg -s ServerName -test -alltests
Note: when you run Eseutil, you can move database files to temporary locations to make repairs. But to run Isinteg, you must put the database back in the location from which it is normally mounted.
At the end of an Isinteg fix run, you will probably see hundreds of warnings. This is normal as Isinteg was originally created as an internal test utility. Just make sure that at the end of a successful Isinteg run, you have zero errors reported. If there is even one error, you should run Isinteg again.
If a few runs of Isinteg do not decrease the error count down to zero, then you should not rely on this database in production. You should move mailboxes from it.
Don't run the integrity check more than 3 times, it isn't recommended, but mine took 2 times.
Some say you should expect to spend an hour per gigabyte of data to get through the whole repair process.
It took me 3 hours on a 9gb database though.
Now remount the store using ESM and all should be good, I only lost some emails from when server was off due to issues.
Now is a very good process to relax, this took me 2-3 days to completed for the private mailbox store, not public.