SUMMARY
This article describes the modification of transaction logs
during disaster recovery of Exchange servers. This process is generally known
as renaming of logs.
back to the
topDefinitions
This article describes the following terms:
Soft recovery
Soft recovery is a process that occurs if an Exchange information
store that stopped abnormally is brought online. When the store stops
abnormally, the checkpoint file tracks which transaction log must first be
replayed to return the database to consistency. Note that soft recovery
requires that EDB/E00.log, the highest log, is present.
Hard recovery
Hard recovery is a process that occurs when you apply transaction
logs and database patch files before Exchange 2000 Service Pack 2 (SP2), to a
database that has been restored from an online backup. Note that hard recovery
does not require that EDB/E00.log, the highest log, is present.
back to the top When not to manipulate log files
Do not manipulate log files if a failed soft recovery on the
database has already occurred. Soft recoveries can fail for a number of
reasons, including a damaged log file. For example, you tried to mount the
store after the server stopped responding, but the mounting failed because one
of the log files was damaged. In this situation do not try to manipulate the
logs in any way. When you tried to mount the store, information about the bad
log file was committed to the database, so the database will not soft recover
if you remove the bad log file or rename the last known good log file to
E00.log.
Example troubleshooting scenario
You are troubleshooting an Exchange Server 5.5 or Exchange 2000
Server computer. The Information Store service terminated and there are 10 logs
files on the hard disk. These log files range from E0000010.log to
E0000019.log, and end with E00.log. You restart the Information Store service.
The Extensible Storage Engine (ESE) then starts replaying the log files, but
reports that the E0000015.log file is damaged. You try renaming the
E0000014.log file to E00.log, and then try to mount the store again. This does
not work. This is designed to fail because damaged information from the
E0000015.log file may have already been committed to the database.
back to the top Completing a hard recovery does not require that log files be renamed
Only manipulate logs files after a database has been restored, but
before hard recovery has completed on the database. Only try to manipulate log
files before you play restored or resident logs back into the restored
database. Note that in this scenario, no log file renaming is actually
required.
Example troubleshooting scenario
Continuing the troubleshooting scenario that was previously
described, the E0000015.log log file has been damaged. Because of this, the
E0000015.log file and all later logs cannot be reused, including the E00.log
file. To make the largest recovery possible, remove all the logs from
E0000015.log to E00.log. Known good logs E0000010.log to E0000014.log will
remain on the disk. Then remove the checkpoint file. After you remove the
checkpoint file, restore the online backup of the database. This restores the
database and any log files that were included on the media backup. The log
files that are restored will all be "older" than the E0000010.log file. When
you have completed the restoration, the Hard recovery runs. The Hard recovery
plays through the logs that were restored from tape, and then continues playing
through logs that resided on the disk, E0000010.log through E0000014.log. After
the logs have been played through, the database is mounted.
Note No log file renaming was required. Hard recovery does not require
that the E00.log file be replayed to successfully complete.
back to the topWhen to manipulate the log files
The only time you should rename log files is if Soft recovery has
not yet failed on the database.
Example troubleshooting scenario
You are troubleshooting an Exchange 2000 Server computer. Logs
E00000A1.log through E00000A7.log and log E00.log are all on the disk. The
Exchange server crashes, and your database is damaged during the crash. When
you investigate, you notice that the E00.log is also damaged. You have an
offline backup of the database from yesterday. When you dump the checkpoint
file, you notice that the last four logs were not committed to the database
before the crash. To recover from this scenario:
- Restore yesterday's offline backup.
- Rename the E00000A7.log file to E00.log.
- Remove the checkpoint file.
- Mount the store.
- Soft recovery runs, playing all the logs into your
database.
- The database has been returned to a consistent
state.
back to the topConclusion
Log manipulation will not work if Soft recovery has already been
tried, but did not work. Only remove damaged (and later) log files if you will
be completing a Hard recovery, complete with a restoration from an online
backup and replaying of available log files. Hard recovery does not require the
E00.log file to complete successfully. Instead, it only requires that damaged
log files are removed before you start. The only scenario when log files can be
renamed is if you restore a previous offline backup, and the log files on the
drive are damaged.
back to the
top