If you are facing the issue 'unable to mount the database' in any version of Exchange Server like 2010, 2013, and 2016, then it is essential to learn the role of transaction logs.
A transaction log is the life-and-blood for an Exchange Server, helping it retain smooth functioning on the server. Every transaction made to the server is being written in these log files, which are then committed to the database. Until the transaction is not saved in the database, it remains the system memory and the transaction logs.
If any crash occurs during this event, then you lose the content from memory during the reboot, because it was not completely saved on to the exchange database files. This is why transaction logs are the robust recovery mechanism to safely restore the data to an Exchange database in a consistent state.
The get the following error message when you are unable to mount the database back to Exchange Server.
Exchange is unable to mount the database that you specified. Specified database: d1cdba46-6f79-46f2- ba14-3ae2fa8aad43; Error code: MapiExceptionCallFailed: Unable to mount database. (hr=0x80004005,ec=-2147467259)
Importance of Log Files
In Exchange Server 2010, transaction logs and checkpoint files are helpful in preventing data loss. The transaction log records all the changes committed in the in-memory database, and checkpoint files record the logged transactions committed on the on-disk database files.
Each database in Exchange Server 2010 has a single set of transaction logs. Actually, the records are written in the transaction logs before they are committed to the database file.
When the database disk is damaged, but the transaction logs are intact, then the restore procedure allows you to restore the media back to the database. The Exchange Store accesses the transaction log files and replays the previously done database transactions. Later, replay the remaining on-disk transaction log files. Sometimes, the transactions can be failed if the system is failed between two transactions recorded in the logs. In such cases, the transaction log restore will not work properly.
- Deletion of transaction logs, which were pending to be committed in database.
- Corrupt Database.
- Dirty Shutdown State.
Microsoft has provided Eseutil utility to verify whether or not the database is in a clean shutdown state. If isn't in a clean shutdown state, then this inbuilt utility may help you to fix up the issues and bring the database into consistency. And if the data is inconsistent state, then using the below-mentioned resolution, you can restore the information successfully from the backup.
Removal of the log file is one of the common reasons, due to which the database may fail to mount. To resolve the issues, it is essential first to perform a consistency check.
Eseutil tool can be of great help in performing soft recovery. This method is useful to the re-mount the database after an abrupt stop. Follow the steps -
- Run eseutil /mh command
- If the output displays the database in a dirty shutdown state as shown below, then the database is missing a transaction log.
- To bring back the database into consistency, it is essential to replay log files into the database. Run the command in ESEUTIL
eseutil /r /l /d - Then provide the location on which the logs are stored
For example: G:\E_\Program Files\Microsoft\Exchange Server\V14\Mailbox\DAGDB1 - When the repairing process gets complete, then again perform this action: Run eseutil /mh command. Doing so will let you verify that the database is in a clean shut down state or not.
- Now, you can mount the database back to exchange using the command -
Mount-MailboxDatabase -Identity '-DAGDB1.edb' However, if you are still unable to mount the database, then verify the consistency of transaction logs.
Verify and Repair Database Logs Using Hard Repair
Eseutil tool is even helpful in performing hard repair recovery to test the database for any damaged pages. If there are any, then the tool will delete them. Run the hard repair - Eseutil /p '\DAGDB1.edb'
However, if you are still unable to mount the database, then try using a reliable third-party Exchange Recovery tool to efficiently restore data in any condition of damage - even where Eseutil tool fails to deliver the desired result. It is an advanced recovery tool to repair corrupt Exchange database files, without requiring log files or Exchange services. EDB to PST converter tool even allows you to restore EDB files directly to live Exchange Server and to Office 365 mailbox.
