Share via

Exchange Troubleshooting: Role of Transaction logs in recovery

  • Article

While in some cases one would see logs as just space fillers and most of the time useless with Microsoft Exchange, the transaction logs are as important as the database itself. An EDB database without the transaction logs is pretty vulnerable to corruption and cannot handle the load of a lot of users accessing the database and will eventually hog the connectivity to it and become inaccessible.

Another thing is that if we had only the database, it will be all the time open with many connections opening and closing and while some might be interrupted for any reason, you will surely end up with a corrupted database; not counting a lot of issues with performance.

To ensure that the EDB database is healthy and there is a fast access while protecting the database from corruption the process is done by three parts, Server Memory, Exchange Logs and the Mailbox database.

The Server Memory being the first thing that when a user is using Exchange will hit and where the transaction are stored and cached. From here the transactions are saved into the logs which are temporary stored on the hard drive where these truncations are queued. All transactions are saved locally as log files and when a backup of the Exchange Server is done, the transaction are committed and stored on the actual database. At this stage the logs are purged. Having said that, backup takes a very important role in this as during the day a very good number of logs will be created and you won’t like it if you end up with a drive full and the databases dismounted.

So yes, transaction logs are a vital part for a healthy database and a well running Exchange Server. If you are setting a new Exchange Server it would be recommended to setup your EDB database and the transaction logs on separate hard drives not for performance but more for recovery purposes in case of hardware failure. So how would this be useful if the database is lost? Well, technically if you had every transaction log from the creation of the database till when the database was lost, you can create a new database and recover the data from the transaction logs. Mind you, you would need every transaction log. This process is called a Replay logs. It is important that when you backup your Exchange Server you don’t just backup the files and your backup software must be Exchange-Aware as this will ensure a good and healthy backup of the database, commit of the logs to the database and purge of the logs. This way you can ensure yourself that you have a healthy backup of all your Exchange databases. Please make sure that you don’t manually delete any log files. These must be only purged by a backup software as this might cause inconsistence of the data with the result of your database unable to mount as it cannot find a particular log file and it will drop into a dirty shutdown state. This can be seen by running the command 

eseutil /mh “path of EDB file”

In case of a catastrophic failure you won’t be able to open the log files directly like a normal text log file. You will only see garbage when you open the files using notepad or any other text editor. Since the size limit of the transaction logs if of 5MB each if you send an email of with a 10Mb attachment, it might be spread into two logs or more.

In order to protect yourself and making sure that Server Memory, Logs and Database are happy and healthy you need to follow the below simple rules.

  • Full backups on a regular basis using an Exchange-Aware application to ensure the purging of log files and clearing storage.
  • Having resilient storage, being on RAID or on a SAN to have high availability in case of hardware failure and to ensure high availability
  • Separating the database storage from the logs storage as the logs are high on disk access, these should be moved to a faster storage.
  • Refrain from storing the logs on compressed storage with the intention to save space as this will highly hinder your Exchange performance.
  • Ensure that there is ample space as a lot of log files are created during the day.

Although you have the above in place and tested on a regular basis, trouble can always come in your way and there are many thing that could go wrong which will make sure to give you a hard time. So let’s take in consideration that something went wrong due to a bad patch, sudden power cut of the server, hardware issue or malware your database won’t mount. After trying to mount it you will get the generic error saying unable to mount database.

In summary to affect a log reply the first thing to do is to run the ESEUtil /ML application to ensure the database is healthy but you notice that the line showing that there are some missing log files. Here you will be able to identity the missing log files. You rename the last log file as E00.log which will be used as the last available log file for the database. You would then run the ESEUtil /R to run a soft recovery. 

Eseutil /r E00 /d “edb file path”

This will go through all the local log files and will top at the last available file. All the newer logs after the missing one will be discarded and lost at this stage.  After the recovery is done and your run the ESEUtil, the state should be Clean Shutdown.

As said when disaster strikes you need to access some data loss and although the below works, it might not work as there are different types of corruption, environments and possible outcomes to the process.  Make sure to always have a good and healthy application backup of your Exchange server.