Summary: In Exchange Server, logs play an important role in keeping the database consistent and mounted (online). If the server shutdowns due to a crash, power failure, or other issues before the logs are committed, it can lead to an inconsistent or corrupt database. In this article, we have shared solutions to find and replay the uncommitted transaction logs on Exchange database files to bring them to a consistent state and mount them to restore mailbox connectivity.
Exchange Server works on the Write-ahead logging (WAL) technique, where changes are first recorded in the transaction logs before they are committed to the database (.edb). This helps ensure consistent server performance.
When you manually dismount a database, the Exchange Server flushes all the transactions in the memory, logs into the database, and commits any pending transactions to the database before dismounting the database.
However, if the server shutdowns abruptly due to a crash, power failure, or hardware failure, the changes recorded in the transaction logs are not committed to the database. As a result, the database becomes inconsistent or corrupt and dismounted from the server. This leads to downtime, preventing users from accessing their mailboxes or sending and receiving emails.
Fortunately, you can find and replay the uncommitted transaction logs on the database and bring it back to a consistent state. Once it’s consistent, you can mount it on the server to restore connectivity.
Below we have discussed how you can find and replay the pending transaction logs in Exchange Server to fix dismounted, inconsistent or corrupt databases using the built-in EseUtil and a third-party Exchange recovery software.
Steps to Find and Replay Log Files in Exchange Server
Now that you know the importance of the Exchange log files in keeping the database consistent and online, you can run Soft Recovery on the database using the EseUtil — a command line-based tool to recover inconsistent databases. Soft recovery replays the pending log files on the database, thereby bringing it to a consistent or Clean Shutdown state.
However, you must find the logs that need to be replayed on the database to fix the inconsistency or corruption.
For this, you can check the status of the database, i.e., whether it’s in Clean Shutdown or Dirty Shutdown state, using the following command.
Eseutil /mh <path to the database>
The output will display the status. For example, if the status is Dirty Shutdown, it will also list the logs that must be replayed on the database to fix and mount it online on the server.
Copy the log name and look for it under the database location and drive. In some cases, the logs remain in the default directory where the database is located, or if you use a different drive volume, you can find the logs there.
At this stage, you try to recover the database from a Dirty shutdown to a Healthy shutdown state by running the soft recovery where the uncommitted logs are replayed on the mailbox database. The command is as follows:
EseUtil /R E00 /l D:\MBX01\Logs /s D:\MBX01\Logs
If the operation fails with the below error, it indicates missing or corrupt logs.
Log file: D:\MBX01\Logs\E00.log ERROR: Log damaged (unusable). Last Lgpos: (0xb8c2d,35,0). Error 501
Operation terminated with error -501 (JET_errLogFileCorrupt, Log file is corrupt) after 11602.418 seconds
In such cases, error -501 (JET_errLogFileCorrupt, Log file is corrupt) is common. Here is the short video to fix this error:
Once you fix it, check the database again using the EseUtil /MH parameter to identify the missing log files. State: Dirty Shutdown Log Require 230-255 (0xe6-0xff) Log Committed: 0-255 (0x0-0xff) Log recovering: 255 (0xff
As you might see from the above, there is no way to know exactly which log file is missing.
However, there is a way to make the Exchange Server think that the latest available log files in the sequence are the last available.
For this, you will need to rename the log file to E00.log, which will make it look last available log file for the database.
You may now re-run the EseUtil Soft Recovery.
EseUtil /R E00 /l D:\MBX01\Logs /s D:\MBX01\Logs
In some cases, this works, and the soft recovery runs without error.
One has to note that the replay log file process will stop at the last available log file. Therefore, all the new transaction logs will be discarded after the missing one.
Once the process is done, you can re-run the EseUtil /MH parameter to check if the database is in a Clean Shutdown state or not.
Please note that this can take a considerable time if you have a large database, such as 20GB or more. Wait until it finishes. Once you verify the status, you can use the Mount-Database cmdlet to mount the database on the Exchange Server.
However, if this doesn’t work, you can check whether the logs are corrupt.
eseutil /ml <Log-file-Path\LogPrefix>
This will show whether the logs are corrupt or healthy. You can only replay logs when they are not corrupt. Otherwise, you will require Exchange recovery software, such as Stellar Repair for Exchange, to fix the corrupt or damaged Exchange database and recover mailboxes.
Conclusion
One can replay log files to reconstruct the entire Mailbox database, bring it to a consistent or Clean Shutdown state and mount it back on the server. However, if the log files are missing, corrupt, or can’t be replayed, you will need Exchange Recovery software, such as Stellar Repair for Exchange. The software scans the Exchange database and does not requires log files. It extracts the mailboxes from the database and lets you save them in PST format, or you can import these mailboxes to a new or existing healthy database on Live Exchange in a few clicks. The Exchange EDB Recovery software can also export the mailboxes and mail items directly to Office 365.
