|   | ![]() |
|
Backup Overview 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 The command to backup a transaction log is as follows:
The command to backup a transaction log is as follows with the myriad options the same as described in the options table previously.
You will find three additional options in the backup transaction command that have not been discussed previously. These options are truncate_only, no_log, and no_truncate.. These options have been provided due to the unique nature of the transaction log. There are times when you do not want to store or retain the transaction log for recovery purposes. This can occur in databases where lareg transactions have been processed but recreating the modifications can be accomplished more quickly than the restore of the transaction log. This is also an extremely useful option to use just before a full database backup. During a full database backup, the inactive portion of the transaction log is also backed up and then applied if the need to restore arises. To speed up the backup of the database, most administrators will truncate the transaction log using the truncate_only option immediately before a full backup. It is also used very frequently on development servers. When you use the truncate_only option, a backup device is not specified since the inactive portion of the transaction log is discarded and not backed up. There are times when the transaction log can fill up and no further entries are able to be written to the transaction log. The truncate_only option will write an entry into the transaction log that marks the point where it was truncated. Since the transaction log is full, this command will fail. The no_truncate provides the same funcationality as truncate_only, except it does not write an entry into the transaction log. Just like in the truncate_only option, a backup device is not specified since the inactive portion of the transaction log is removed. The no_truncate option can be used in several cases, but normally has one use. If a database becomes corrupted a restore of your most recent backup is necessary. However, a number of transaction could have been processed and would be lost. As long as you can still connect to the database and the transaction log is readable, the no_truncate option allows you to backup the inactive part of the transaction log to the point of corruption. This can give you the ability to bring the database back to the last state it was in without any data loss. The difference between no_log and truncate_only in previous versions of SQL Server caused great confusion among many DBAs. Because of this, Microsoft changed the behavior of the truncate_only option in version 7.0. Both options now function the same and are completely interchangeable. The no_truncate option does not remove the inactive portion of the transaction log and does accept a backup device. Because of this feature, the no_truncate option can be used to capture the entire transaction log in a single file. This can streamline the restore process, because only one transaction log needs to be restored to bring the database up to date. The no_truncate option is rarely used for this purpose and has been superceded by differential backups when used in this manner. Backup log to an explicit disk device and begin a new backup set.
Backup log to an undefined network disk device and overwrite the existing backups
Backup log to a tape device and leave the tape in the drive
Backup a log to a tape device using a variable
Backup Overview 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 |
All content on this site, except where noted, represents an original work of Michael R. Hotek and is protected by applicable copyright laws. The SQL Server FAQ is the sole work of Neil Pike. No page, portion of a page, or download may be used for commercial purposes in whole or in part without the express, written permission of the applicable author.