How to Repair Exchange 2010 database with Eseutil Switches

 

Among the different tasks an Exchange Administrator is expected to perform on a daily basis is the tricky one where he must ensure that the server keeps running without glitches. And no matter how simple it may seem, it is not. Unexpected technical, software or human errors keep cropping up that interrupt the normal flow of activities on the Exchange server and prompt the Exchange administrator to take measures and get everything back to working. And among those measures lies the knowledge of handy tools and utilities that can save the day when common fixes don’t resolve problems.This article focuses on one of the most widely used inbuilt command line utilities that can be used to repair Exchange 2010 database in situations of Exchange database errors. We’re talking about none other than ESEUTIL utility.

ESEutil and associated switches

ESEutil is a command line utility aimed at repairing minor issues within the Extensible Storage Engine (ESE) or Jet Engine of Exchange database. The utility is available under the Bin Directory and is used in database operations like integrity check, offline defragmentation, database repair, checksum test etc. As already mentioned, it is an inbuilt utility, that is, it is automatically installed along with the Exchange Server. It works on dismounted database and there are a number of switches that can be used with the utility to perform different operations.

Here's a list of ESEutil switches with a brief explanation of each

/d – Defragments the offline database to reduce its gross size on the disk by discarding most empty pages and rebuilding indexes.

/p – Repair: Repairs corrupt Exchange database by discarding pages that cannot be repaired. This mode can thus result in data loss. Moreover, it fixes individual tables but not the links between the tables.

/c – Restore: Displays restore log file and controls hard recovery after restoration from legacy online backups.

/r – Recovery: Replays transaction log files to restore a database to internal consistency

/g – Integrity: Verifies page level and ESE level logical database integrity.

/m – File Dump: Displays database file headers, transaction log files, checkpoint files, page header information, database page allocation, and metadata.

/k – Checksum: Verifies checksum on all database pages, log files, and checkpoint files.

/y – Copy Files: Performs a fast copy of very large files.

Why Eseutil is needed?

Now that we understand the different aspects of the Eseutil command-line tool, let’s investigate its actual need. The ESE or Jet Engine of an Exchange database includes data served in “Pages”. For Exchange 2010, each page is of size 32KB and the EDB file contains multiple such pages.

Whenever a read/write/update operation (or transaction) occurs on the database, it is first written to the memory, then to the log files and finally to the database. This process is known as Write-Head Logging. For a database to be consistent, all transactions recorded within the log files must be committed to the database (EDB files) before the database is shut down. Only then is the database regarded as “detached” from the log files and in a clean-shutdown state. However, if the server shuts down unexpectedly (server crash or due to power failure) while there are still transactions pending to be committed, the database is considered to be “attached” to the log files and in a dirty-shutdown state.

In such a case, on restarting, the server performs automatic Soft Recovery where log files are replayed using the Checkpoint file to make the database consistent again. This works for most of the cases. And when the problem doesn’t fix automatically, the administrator can manually perform a hard recovery using Eseutil tool. In cases of page-level database corruption too, Eseutil comes in handy to correct things.

15 Steps to repair Exchange 2010 database using Eseutil?


Step 1. Check if the database is consistent or not by running: eseutil /mh:

  • If database shutdown state is 'Clean', move all log files from the transaction logs folder and then mount the stores.
  • If database shutdown state is 'Dirty', check if the log files mentioned as "Required" are available or not.
Step 2. Check the status of "required" log files with the command: eseutil /ml .This command will check the health of all log files at the location.
Step 3. If the log files are healthy, Soft Recovery will put things back into place. Perform a soft recovery with the following command:
Eseutil /r /l "Path of the log files" /d "Path of the database" 
After completion of the command, mount the stores.
Step 4. In case you encounter JET_errAttachedDatabaseMismatch (error -1216) after a few seconds, run soft recovery with /i switch at the end to override the EDB-STM mismatch. 
Step 5. If log files are not healthy or are unavailable, the database can be restored from backup or a hard recovery can be performed. 
Step 6. If restoring from backup, once the restoration completes, a file called restore.env is created in a temporary location. This file contains the logs that were backed up without being committed to the backed up database.
Step 7. Take a copy of this temporary folder and store it somewhere safe.
Step 8. Now perform Hard Recovery from the Bin folder with this command:  Eseutil /cc "Path of the restore.env containing folder" 
Step 9. Now, again check the temporary folder that contained restore.env file. If the hard recovery was successful, the folder would be empty. 
Step 10. Now mount the stores successfully.
Step 11. If a valid backup is not available, perform Hard Repair with this command: eseutil /p
Step 12. Choose "OK" on any prompt that you get. 
Step 13. This is the complete repair process. Once these steps complete successfully, to finish up, defrag the database offline with this command:  eseutil /d 
Step 14. Now mount and demount the store immediately and then use the ISInteg tool to fix any issues   isinteg –s -fix –test –alltests 
Step 15. If still the database is not mounted then try Stellar Phoenix Mailbox Exchange Recovery Software to repair corrupt Exchange 2010 database. You can download the software from here: 

To sum it Up

This is the complete process of repairing Exchange 2010 database using the inbuilt ESEUtil tool. However, this tool might not be able to fix issues within EDB files in all cases. Moreover, it might result in data loss as mentioned earlier.

To overcome these limitations, thus use automated EDB repair software Stellar Phoenix Mailbox Exchange Recovery. This reliable application repairs even severely corrupted / damaged EDB files and recovers inaccessible mailboxes within minimum time. Its interactive GUI makes it easy to work with and it is compatible with a wide range of Exchange versions. Moreover, the product also offers features like exporting mailboxes to Live Exchange or Office 365, selective mail recovery and more. You can check software steps to repair corrupt EDB file from here

Stellar Phoenix & Stellar Data Recovery are Registered Trademarks of Stellar Information Technology Pvt. Ltd.
© Copyright 2017 Stellar Information Technology Pvt. Ltd. All Trademarks Acknowledged.