Backing up, truncating and cleaning up Exchange transaction logs |
 |
By Jerry Cochran
01 Nov 2004 | SearchExchange.com |
|
|
The following is tip #8 from "20 tips on protecting and recovering Exchange data in 20
minutes," excerpted from the book, "Mission Critical Microsoft Exchange 2003" (Digital
Press, a division of Elsevier, Copyright 2004). For more information about this book and
other computing titles, please click here.
Return to the main page for
more tips on this topic.
During a full backup operation, the transaction logs must be stored to the backup set next.
Remember from above that the checkpoint is halted at the beginning of backup (for a full
backup). Even though the checkpoint is halted, transactions continue to be written to the
log files, and dirty pages from the database cache in memory are flushed to disk during the
backup operation.
Note that with Exchange 2000 SP2 and later, dirty pages that cause patching operations are
not flushed; this is how Microsoft was able to get rid of the patch files in SP2. In order to
back up the log files, the backup application requests a list of log files (and patch files if
applicable) from ESE (via the HrESEBackupGetLogAndPatchFiles API call). When ESE
receives this call, it closes the current log file as the next log generation and opens a new
E0n.log. In the case of a full backup, ESE then returns a list of log files to the
backup application that starts with the current log generation where the checkpoint is
halted and ends with the generation of the log file that was just closed (E0n.LOG --
1). In the case of an incremental or differential backup, ESE returns a list beginning with
the oldest generation on disk up to the most recent log file closed (E0n.LOG -- 1). During
incremental, differential, and copy backup operations, only log files are backed up and the
checkpoint is not halted. Using this list of files, the backup application can open file
handles to the logs and copy them to the backup set (using the HrESEBackupOpenFile,
HrESEBackupReadFile, and HrESEBackupClose-File). During these operations, ESE also
ensures that no log generation is missing from the sequence passed to the backup
application. This operation will continue until all relevant log and patch files have been
written to the backup set by the backup application.
Truncating the logs
Since the log files have been stored to a backup set, they are not needed on disk. ESE will
then truncate the log files during full and incremental backup operations. When ESE receives
the call from the backup application to truncate the logs (HrESEBackupTruncateLog API
call), it will truncate the log files on disk. Which log files ESE truncates is determined by
the lowest generation of (1) the checkpoint log file generation, or (2) the log generation
listed in the database header (you can view this using the ESEUTIL program with the /MH
parameter) for the current full backup.
Cleaning up
Once the log files are truncated, the backup operation is complete and the backup set is
closed. At this point, ESE can return to normal operations and allow the checkpoint to
advance forward. To complete the backup operation, the backup application calls
HrESEBackupInstanceEnd to end operations for that instance of backup. At this point
ESE is able to allow the checkpoint for the storage group instance being backed up to
advance and normal database operations to recommence. Finally, the backup application calls
HrESEBackupEnd to disconnect from the information store process allowing it to return
to normal operations.
Get more "20 tips on protecting and recovering Exchange data in 20 minutes". Return
to the main
page.
About the author: Jerry Cochran is a contributing editor for Windows IT
Pro and Exchange & Outlook Administrator and a group program manager for
Microsoft. He is the author of Mission-Critical Microsoft Exchange 2000 (Digital
Press).
|
|
|
|
