Toll Free: +1 888 900 4529 |   Toll Free: +44 800 088 5522

Exchange Database Recovery without Log Files – Discussed Properly

Mike Jackson | July 28th, 2014 | general

Exchange Transaction Log: Exchange transaction logs are responsible to manage records for changes made into Exchange databases using distinct commands like:

  • Insert
  • Update
  • Delete

The required information first gets added to the Exchange logs before being written to Exchange Server database. Once the information will add up into Exchange Server, it means the actions are recorded even committed at Extensible Storage Engine. In case if any log details are not recorded then there will be operation failure.

How Exchange Transaction Log Works?

Exchange log files not only hold data but also keep associated actions and if these files will be absent then, exchange database recovery without log files will not be possible. The Write-Head logging technique used by Extensible Storage Engine is for resolving failures enlisted as:

  • Hard disk failures
  • Power interruptions
  • System failures

The concept of this terminology for writing data to the Server is:

Adding up data to the hard disk through transaction log-> Transferring data from hard disk to Exchange Server.

Caching of data that is recently added to the hard disk gets done instantly but, it will not reflect to the Server. For all the operations made into Exchange database, there will be a proper manner for adding up those into a sequence. This is all about to manage transaction log in quick manner. Sustaining records for fickle data that will not be stored into main database is all about creating log files. Getting back to the last transaction state that is committed plays the role of silver lining when actual database goes out of reach. In case if database is corrupt one can retrieve that with the use of transaction log. Caring and rescuing transaction log files treated as quite important task because, it prevents Exchange databases from being damaged.

Replay Exchange Transaction Log Files

Into two states Exchange Server will not be in running mode and these are

  • Clean Shutdown
  • Dirty Shutdown

According to these states, databases are elaborated as:

  • Consistent Database: When all the actions are committed to the database successfully and transactions are done properly by detaching the logs and databases then, this will be called as Clean Shutdown state and database will be called as consistent.
  • Inconsistent Database: While transactions are to be written into database but during the process the Server gets down then associated logs are not detached from databases. This state is called as Dirty Shutdown and database will be called as inconsistent.

Verifying the state of database with command:

eseutil-mh

Recovery is the situation where Exchange transaction logs will be replayed into databases those are restored. This task can be categorized as:

Soft Recovery: This is all about to replay the transaction log for a re-mounted database that is suffering from un-desired halt. In this stage, Exchange Server completes actions those are not committed by retrieving the checkpoint.

Under this category of exchange database recovery without log files, offline Exchange database will be recovered with the use of ESEutil utility, for the process given command should followed:

eseutil-renn

Hard Recovery:

The process is applicable to replay log files for databases those are restored from online backup. If “Last Backup Set” option is enabled then, restoring backup will be done automatically. It is quite different from soft recovery because it does not use concept of Checkpoint. Instead of that Restore.env file may be opted for replaying log files.

No matter if “Last Backup Set” is not enabled, the restoration can be executed with ESEutil usage through manual process.

c-temp

Instead of Exchange EDB file, if recovery is to be executed into restore.env then, syntax for the same will be:

restore.env

The process will work only for those Exchange databases those are restored from valid online backup so; there will not be any recovery process for other Exchange files. And files those are restored should associate with restore.env file.

What to Do – When Exchange Log Files Are Not Present

Above defined processes are dedicated to make databases consistent. It is simply all about to transfer non-healthy data into healthy manner. For repair process, it is required to keep log files into healthy mode. Situations where log files affect the process:

  • Replay process will not execute successfully if any log file is missing
  • Missing log files may lead to generate errors during the process

Example of Error:

error-514-1

Due to unavailability of log files, if there is an issue to get back consistent state of database then, the process to repair Exchange database will be executed with Eseutil/p command.

eseutil-p

Note: Any broken link into tables, records, corruption in Exchange page, or unwanted actions may lead to data loss while Eseutil is running for exchange database recovery without log files. To come out such situations, B-tree structure recovery and offline defragmentation processes will have to follow.

The availability of external technical solutions is helpful to make Exchange databases consistent without applying additional efforts. Exchange Recovery software is best suited to get back EBD in accessible mode after restoring into EDB, PST, MSG and EML. At the other end, repaired EDB data will be restored into other Exchange Server as well regardless of being dependent on log files.

The following two tabs change content below.

Mike Jackson

Mike Jackson is a technical writer and he wrote numerous blogs or articles regarding Exchange Server corruption issues with their solutions. You can follow him on Google+, Facebook and Twitter. If you have any query & solution regarding Exchange Server & Outlook apps then you can mail Mike at mike.edbtopstpro@gmail.com.