As discussed, the full and
bulk-logged recovery models cause transactions to be written to the
database’s transaction log. These transactions should be backed up
periodically for two main reasons. First, the transaction log backups
can be used in case of a media failure to restore work completed in the
database. These backups limit your exposure to data loss and enable you
to reapply changes that have occurred.
The
second reason for backing up the transaction log is to keep the size of
the log manageable. Keep in mind that SQL Server is a write-ahead
database management system (DBMS) and thus writes most changes to the
transaction log first, before it updates the actual data files. This
type of DBMS is great for recovery purposes, but it can be a real
headache if you do not periodically clear those transactions from the
log. Without a backup or manual truncation, the log can fill to a point where it will use up all the space on your disk.
Creating Transaction Log Backups with SSMS
The same backup screen utilized for database backups in SSMS can also be used for transaction log backups. Figure 4
shows the Back Up Database window with Transaction Log selected as the
backup type. A device must be selected to write the backup to, and some
additional options on the Options page that relate to the transaction
log are enabled.
Creating Transaction Log Backups with T-SQL
When you back up a transaction log by using T-SQL, you use the BACKUP LOG command, which includes all the previously listed options except the DIFFERENTIAL
option. (Differential backups do not apply to transaction logs.)
Several additional options are available for transaction log backups.
The following abbreviated syntax for the BACKUP LOG command shows the options used exclusively for backing up transaction logs:
BACKUP LOG { database_name | @database_name_var }
TO < backup_device > [ ,...n ]
[ [ MIRROR TO < backup_device > [ ,...n ] ] [ ...next-mirror ] ]
[ WITH
......
[ [ , ] NO_TRUNCATE ]
[ [ , ] { NORECOVERY | STANDBY = undo_file_name } ]
The options specific to BACKUP LOG are discussed in detail in the following sections.
The NO_TRUNCATE Option
You use the NO_TRUNCATE
option when the log is available, but the database is not. This option
prevents the truncation of the transaction log after a backup occurs.
Under normal circumstances, the BACKUP LOG
command not only writes to the transaction log, but also signals a
checkpoint for the database to flush any dirty buffers from memory to
the database files. This behavior becomes a problem when the media
containing the database is unavailable and you must capture the current
contents of a log to a backup file for recovery. If you last did a log
backup four hours ago, this would mean the loss of all the input since
then. If your log is on a separate disk that is not damaged, you have
those four hours of transactions available to you, but BACKUP LOG fails because it can’t run a checkpoint on the data files. You run BACKUP LOG with the NO_TRUNCATE
option, and the log is backed up, but the checkpoint is not run because
the log is not actually cleared. You now have this new log backup to
restore as well, enabling recovery to the time of failure. The only
transactions lost are those that were not yet committed.
The NORECOVERY | STANDBY= undo_file_name Options
The NORECOVERY option causes the tail of the log to be backed up and leaves the database in a RESTORING
state, which allows additional transaction logs to be applied, if
necessary. The tail of the log is the active portion of the log that
contains transactions not yet backed up. This “tail” is critical in
restore situations in which all committed transactions are reapplied.
Typically, the NORECOVERY option is used with the NO_TRUNCATE option to retain the contents of the log.
The STANDBY option also
backs up the tail of the log, but it leaves the database in a
read-only/standby state. The read-only state allows inquiry on the
database and allows additional transaction logs to be applied to the
database as well. undo_file_name must be supplied with the STANDBY
command so that transactions not committed and rolled back at the time
of the backup can be reapplied if additional transaction logs are
applied to the database. This STANDBY option produces the same results as executing BACKUP LOG WITH NORECOVERY followed by a RESTORE WITH STANDBY command.
Note
As mentioned earlier, Microsoft has removed the NO_LOG and TRUNCATE_ONLY
options available with earlier versions of SQL Server, including SQL
Server 2005. Setting a database to use the simple recovery model is the
alternative to these options.
