How to Recover Exchange 2010, 2007 Database Without Log Files

0
2397

Exchange database is synonymous to the storehouse of information as it contains abundant data in form of user mailboxes consisting of email messages, calendars, notes, tasks, etc. Thus, Exchange database administrator has the entire responsibility of keeping the data of thousands of users intact, safe and secured. Anything that hampers data is strictly taken care of because data loss can not be afforded in organizations dealing with crucial information. To prevent big data losses from happening, time to time data is archived. This backing up of data minimizes every risk and ensures that server will never be out of running state for long.

Basically, the simplest technique to repair a damaged Exchange server is by opening a recent data archive and that is how the database is recovered. Exchange transaction log files play a significant role in data recovery from its archive. This article throws lights on the significance of transaction log files and further highlights how to recover Exchange 2010 database without log files or recover Exchange 2007 database missing log files.

Significance of Transaction Log Files

Exchange server is also referred as a transaction based email application in a lot of aspects. A transaction can be defined as an assembly of functions that are executed against server database. These functions include updation, insertion or deletion of data, while it is assumed that ACID properties of the database are retained.

Now, transactions dwelling inside database log files are recorded for maintaining track record of every change that affects the Exchange database. This track record is maintained so that even if something goes wrong, previous transactions can be reversed. Thereafter, the database is restored in the running state. This is known as Rolled Back.

In the times when server damages abruptly, the transaction of files are of huge importance as it accepts entries up to fraction of seconds as well. Even Exchange archive and its recovery depends on these log files. First and foremost, every transaction is written in transaction log files on hard disk and then, these are committed from log files to database of server. There occurs a little gap in between and this delay gives DBAs the space to copy log files to different disks as backup.

These backup files are of a great help in times of crisis or when the database is in danger. Log files are easily replayed to repair or recover data till last committed transaction if and only if the database is available and in healthy state. As now we are aware of the importance of log files so, let us take a quick glance at some of the situations of Exchange database recovery without log files.

Inconsistent Vs Consistent Database

Database consistency is the core entity of ACID properties. Exchange database should be in a healthy state to be called as healthy. Moreover, before the shutdown, all transaction log files must be committed to Exchange database. If it occurs this way then, the database server is seen as detached from transaction log files. This state is referred to as Clean-Shutdown state.

But suppose there are few transactions that are not committed to database and server gets shutdown abruptly or unintentionally due to any reason, be it any power failure, hardware problems, surge, etc. then, the good point is that still database will remain attached to log files. Therefore, the unwritten pages are known as Dirty. Now, as long as these dirty pages are inside Exchange database, the state is known as Dirty-Shutdown state. If anyone wants to know the database state t any time then, use ESEUTIL command in the following manner.

ESEUTIL /mh Restore & Recovery of the Database

Before beginning our main topic, it is important to know the basic difference between the terms Restore and Recovery. Although the two terms are used synonymously, yet they have a major difference. Restore consists of uploading log files to the original location of Exchange server whereas, Recovery lays emphasis on repaying log files to the database that has been restored. This clarifies the major significance of log files in Exchange database recovery process.

Exchange 2010, 2007 Database Recovery Without Log Files

By ESEUTL Command: In the presence of transaction log files, it is very simple to recover server database with the help of ESEUTIL commands. However, if log files are unavailable then following are the two methods to execute the recovery process.

  • Replay operation will be completely unsuccessful.
  • Recovery operation will halt with errors.

Common Errors Encountered:

ESEUTIL command is useful as it can be equipped to recover server database in presence as well as absence of transaction log files. If one wishes to recover Exchange database without log files then, use this command with /p switch as eseutil /p

Limitation:

Eseutil command works well but sometimes may even lead to data loss if ESEUTIL encounters damaged or corrupted database pages or broken links between tables, etc. Moreover, in case, deletion of internal pages is needed for structure improvement, data may get misplaced. Hence, user has to recreate server database with the help of offline defragmentation. After wards, B-tree database structure is rectified. This too is again a very time-taking process.

Limitation:

To escape the above risks and issues mentioned above, it is advised to go for the professional, third party EDB to PST Converter software. This software is built in such a way that it effectively migrated data from Exchange server to PST format. The tool will also repair and recover corrupted Exchange database in no time. Thus, the tool is an all-rounder tool that figures out all the issues linked with a corrupted database and it also has the potential to recover Exchange 2010, 2007 database without log files.

Few Closing Thoughts

In this article, every important aspect about transaction log files has been jotted along with the common errors that crop up. Moreover, effective resolution methods to recover Exchange database missing log files has been precisely highlighted here. Though there is a manual method by ESUTIL command however, go for EDB to PST Converter tool for flawless results.