ESEUTIL in Exchange 2007 and lost log resilience (LLR)

Below information is collected from internet as it is, to have it here available for all of us. I have included the links pointing original location of the post. I will be keep posting handy little articles as I come across. I just want to point out the new future called "Lost Log Resilience and Transaction Log Activity in Exchange 2007". LLR enables to recover Exchange databases even if one or more of the most recently generated transaction log files have been lost or damaged

The Exchange Server Database Utilities (Eseutil.exe) is a tool that you can use to verify, modify, and repair an Exchange database file. When a database is corrupt or damaged, you can restore data from backup or repair it using ESEutil. ESEutil works with the Extensible Storage Engine (ESE), database files, and log files associated with a Microsoft Exchange database.

ESEutil is located in the Exchange default install folder, which is

<SystemDrive>:\Program Files\Microsoft\Exchange Server\Bin.

ESEutil can be used against any ESE database in Exchange Server 2007. In the past, ESEutil could only be used with mailbox and public folder ESE databases, but with Exchange 2007, ESEutil can be used with ESE databases on the Exchange 2007 Hub Transport and Edge Transport server roles as well.

ESEutil can be run on one database at a time from the command prompt. You can use ESEutil to perform a range of database tasks including repair, offline defragmentation, and integrity checks. Table 1 lists the most common ESEutil switches.

ESEutil examines the structure of the database tables and records at the low level of the database (Ese.dll). You can use the defragmentation mode to compact a database offline. Other ESEutil modes such as repair, recovery, and restore can be used to repair a corrupt or damaged database. Modes like integrity, file dump, and checksum can be used to verify the state of a database

ESEutil mode	Switch	Description
Defragmentation	/D	Defragments the database offline but leaves the new, defragmented database in the temporary location with or without overwriting the original database. This mode reduces the gross size on the disk of the database (.edb) by discarding most empty pages and by rebuilding indexes.
Repair	/P	Repairs a corrupt offline database by discarding any pages that cannot be fixed. In repair mode, the ESEutil tool fixes individual tables but does not maintain the relationships between tables. Use the Information Store Integrity Checker (Isinteg.exe) tool to check and fix links between tables if the repaired database is a mailbox or public folder database.
Restore	/C	Displays restore log file (Restore.env file) and controls hard recovery after restoration from legacy online backups.
Recovery	/R	Replays transaction log files or rolls them forward to restore a database to internal consistency or to bring an older copy of a database up to date.
Integrity	/G	Verifies the page level and ESE level logical integrity of the database. Does not verify integrity at the application level. Application-level logical integrity can be verified with ISinteg for mailbox and public folder databases.
File Dump	/M	Displays headers of database files, transaction log files, and checkpoint files. Also displays database page header information, and database space allocation and metadata.
Checksum	/K	Verifies checksums on all pages in the database, log files, and checkpoint files.
Copy File	/Y	Performs a fast copy of very large files.

ESEutil /R Recovery Mode

• Hard recovery A transaction log replay process that occurs after restoring a database from an online backup. Hard recovery occurs when transaction log files must be replayed into a restored online backup. In all other recovery scenarios, soft recovery is done. Hard recovery can be done with Exchange Server Database Utilities (Eseutil.exe) by using the Restore mode (/C).
  
• Soft recovery A transaction log replay process that occurs when a database is remounted after an unexpected stop, when transaction logs are replayed into an offline file copy backup of a database, or when logs are replayed into a Volume Shadow Copy Service (VSS) backup set. In the default soft recovery scenario, an external event unexpectedly stops an Exchange database, but the database and log files remain intact and in place. When the database is mounted again, Exchange reads the checkpoint file and begins to replay the transaction log that is listed as the checkpoint log. If no checkpoint file exists, replay begins with the oldest log file available in the transaction log folder for the storage group.
  

  Exchange writes to the database files completed transactions found in the log file that have not already been written and reverses any incomplete transactions. Exchange never begins writing a transaction into the database files until all the operations composing it have been secured to the log files. You do not need to physically undo or stop a transaction in the database if all uncommitted transaction logs present at the time of the unexpected stop are present when replay begins
  

  Recovering a database with missing log files
  

• In Exchange Server 2007, a new feature called Lost Log Resilience (LLR) protects Exchange databases from losing the last few log files and enables faster recovery. When an LLR-protected log file is missing or corrupt, normal database mount or recovery with ESEutil fails without the new /A recovery option. An event log with Event ID 523 states the type of failure. You can run ESEutil recovery on a database when an LLR-protected log file is missing or corrupt by using the /A option in recovery mode as follows:
  

  ESEUTIL /R Enn /A
  

  http://technet.microsoft.com/en-us/library/bb123479.aspx
  

  Oz Ozugurlu