Database Recovery Strategies
This section explains the structure of a database and discusses database recovery strategies.
Understanding Database Structure
To understand how a database is structured you should understand page levels, Exchange Store Engine (ESE) table levels, and application levels of a database. The following is a quick description of each level:
Page level: The file contains an ordered series of pages (typically 4 kilobyte or a multiple of 4 kilobytes), with each page sharing a common organizational structure. Each page has page header information and page data. The header information includes the checksums for the page that enable Exchange to verify data integrity and to correct single-bit errors on the page.
ESE Table level: Groups of pages are owned by tables that are managed by the ESE database engine. A typical Exchange database contains thousands of individual tables.
Application level: ESE is a general purpose database that can be used by different applications. For example, both Exchange and Active Directory directory service use ESE. The ESE database engine stores information in its tables as directed by a particular application. ESE itself does not understand the application-defined relationships between tables or the meaning of the data stored in each table.
Understanding Database Recovery Strategies
The most basic strategy for recovering from database file damage is to restore a known good copy of the database from backup and to roll the database forward using subsequently generated transaction log files. To use this strategy, the following three assumptions must apply:
You have a good backup of the database.
All transaction log files generated since the backup are available and undamaged.
The problem in the database is not caused by a logical corruption or unintended deletion. For example, if a virus scanner was to corrupt messages or delete them, then the corruptions and deletions would be part of the transaction log record and would be replayed into the database after restoration from backup.
Other database recovery strategies are described below.
Move Mailboxes
When you move an Exchange mailbox to a different database, the contents of the mailbox are processed by the Exchange Information Store just as when they were created. Items that have been damaged will be skipped. Therefore, moving all mailboxes to a new database is an excellent strategy for removing damaged items while at the same time maximizing the amount of salvaged user content.
After a mailbox has been moved, Outlook client profiles will be automatically updated to point clients to the new database or server. For this to occur, the previous server must remain online with its Information Store service that is running until after all clients have logged on one time and have been redirected. If the previous server is not kept online, then Outlook client profiles must be updated manually or through scripts.
Previous offline or cached mode client files will continue to work after a mailbox has been moved. Client rule functionality is also preserved when a mailbox is moved.
Moving a mailbox has the same effect on the destination server as redelivering all the items in the mailbox at one time. Therefore, if you are moving many mailboxes, it is best to do the operation at off-peak times, and to provide clients information in advance about when the move will occur and about how to receive help if they experience problems logging on after the move.
Moving many mailboxes will cause a larger than ordinary number of database transaction log files to be generated for the destination database. You should closely monitor transaction log disk space on the destination server during a bulk mailbox move operation. If you are close to running out of transaction log disk space, you can run an online full or incremental backup to clear the log files or enable circular logging before the move and then disable circular logging right after the move.
Moving all mailboxes to a new database, and discarding the previous database, maximizes the preservation of salvageable user content while at the same time minimizing database downtime.
For information about how to move an Exchange database to another server or storage group, see Moving an Exchange Mailbox Database to Another Server or Storage Group.
Repair the Database
Generally, you should repair a database only when it is infeasible to restore the database and roll it forward. Frequently, repairing a database will take more time than restoring from backup.
Note If the database is severely damaged, repair will take longer to run, and the probability of a successful repair is less likely. If you run repair on an undamaged or only slightly damaged database using typical enterprise-class server hardware, the process will usually take about an hour for every 5 GB of data. If you are calculating repair times as part of designing Service Level Agreements (SLAs), you should perform your own benchmarks on a typical database running on hardware similar to that used for Exchange in your organization. If a database has been severely damaged, repair times may increase by a factor of 10 or more.
For more information about how to use Eseutil to repair a database, see Eseutil /P Repair Mode.
Restore, Repair, and Merge
Restoring, repairing, and merging a database is frequently called a hybrid strategy. It can be used when you have a good backup of the database, but do not have all the transaction logs created after the backup.
In this case, you can restore the backup, and in parallel, repair the damaged copy of the database in a Recovery Storage Group on the same server or on a laboratory server. You can then use the Recovery Storage Group feature to mount both copies of the database separately and merge data from the repaired database to the restored database.
Assuming the repair is successful, this strategy has a chance of recovering almost as much data as if you had been able to use the transaction logs. For more information about several hybrid strategies using Recovery Storage Groups, see the guide on Using Exchange Server 2003 Recovery Storage Groups (https://go.microsoft.com/fwlink/?LinkId=47589).
For More Information
For more information, see the following topics in the Exchange Server Database Utility Guide: