Recipe6.12.Rebuilding a Database File from Logs

Recipe 6.12. Rebuilding a Database File from Logs

Problem

One of your databases has become corrupt and you want to restore it using only the transaction log files.

Solution

Using a graphical user interface

1. Ensure that you have all log files from E0000001.LOG through the anchor log. If you don't have every log file created since the database was created (either because you lost one or because circular logging was on), you may have difficulty restoring the complete database contents.

2. Move or rename the EDB and STM files for the target database. Don't delete them; you may want to be able to return to them later.

3. Move the CHK files from the transaction log path for the SG. As with the EDB and STM files, your best bet is to keep these in case you need them.

4. Make sure the IS service is running, either by checking the Services control panel applet or looking in the application event log for event ID 1001.

5. Mount the target database.

6. The store will create new EDB and STM files with the appropriate name in the specified database location.

7. Wait for the IS to finish replaying the transaction logs.

Discussion

If you have an unbroken chain of transaction log files and PRIV1.EDB becomes corrupt, you can quickly and accurately recover the data store by dismounting the database and removing (or renaming, which is much safer) the existing CHK, EDB and STM files. When you attempt to remount the database, the IS will create new, empty EDB and STM files, then it will begin sequentially playing back log files to restore the contents of these files.

Note that the anchor log isn't relevant here; in order for Exchange to restore the contents of the database accurately, you'll need all of the log files. There's no way to tell Exchange "start with log file #5 and go forward from there"; in the case of an empty EDB and STM, the anchor log file will always be the first one. Because this approach requires you to have every log file created since the database was created, it's pretty difficult to find circumstances where it makes sense. In most cases (and assuming a reasonable level of backup planning), it will be easier to fix the database by reloading it from a backup and playing back the needed transaction logs, as described in Recipe 11.4.

See Also

Recipe 11.4 for restoring a database, MS KB 278958 (How to Use Log Files to Rebuild the Priv1.edb File), and MS KB 296843 (How to recover an Exchange 2000 Server database after error -1216)