Sergey Nivens - Fotolia
Use eseutil for Exchange database repair with care
If Exchange crashes and you lack valid backups, just stay cool. The eseutil tool can be powerful, but if used improperly, it can do more harm than good.
When disaster strikes and the Exchange Server crashes without a valid backup, an admin can make things far worse by making a hasty attempt to get the platform back online without careful planning.
Don't rush in and start immediate repairs with the command-line tool eseutil. While eseutil is a powerful tool for Exchange database repair work, use it wrong and it can make matters worse. Admins must understand the different functions of eseutil and when their use is appropriate.
Not every problem requires eseutil
Admins can use eseutil for several significantly different Exchange database repair procedures: to defrag a database, to recover damaged page files or to perform a roll-forward recovery of a database. The roll-forward option restores the backed-up data, then runs the transaction logs to recover the cached data.
But the best time to run eseutil depends on the circumstances. Use it in repair mode solely as a last resort when several things go wrong in the environment. If you can't mount the database and restore backups, it might be your only option.
When database and streaming files don't match
A failure can cause Exchange to dismount a database. This often happens when the streaming file (STM) and the database file (EDB) are not synchronized. When eseutil starts a database repair, it first checks that the STM file is in sync with the EDB file. If eseutil finds those two files do not match, it will error out.
By forcing eseutil to run an Exchange database repair despite this condition, the admin might lose all data held in the streaming file. The following command ignores the mismatch error and runs the repair:
eseutil /P <database>.edb /I
This command has consequences. The STM file primarily holds user data from Post Office Protocol 3 (POP3) and Internet Message Access Protocol (IMAP) clients, so if all clients run Outlook, ignore an STM file mismatch. Conversely, if a large number of clients connect to Exchange servers with POP3 or IMAP, then forcing a repair though an STM file mismatch usually results in data loss.
Restore and roll forward
If the Exchange databases have proper backups, restore and roll forward a database rather than attempt a repair.
This process takes less time and comes with lower risk of data loss. By comparison, even a lightly corrupted database takes around an hour to repair each 5 GB of the database. With the size of databases in most production environments, that's a significant time investment.
To perform a restore and roll forward, an admin needs two things: a good recent backup of the database and all the transaction logs created after that backup. If both conditions are met, run this command to restore the database and roll it forward:
eseutil /CC
Complete these Exchange database repair steps
Once eseutil completes the repair mode, there are still three tasks to execute before the admin can mount the database.
- Run eseutil /D (defrag) against the database.
- Run isinteg –fix, which uses another Exchange utility to check the integrity of the newly repaired and defragmented database.
- Back up the database.
Management will want the Exchange database mounted and operational as soon as possible, but admins shouldn't skip these steps. While it's possible to mount the database after the eseutil repair finishes, the database is not stable until you complete the first two steps, and it's not safe until the backup is done.
