Brad’s Sure Guide to SQL Server Maintenance Plans- P34 ppsx

Chapter 13: Back Up Database (Differential) Task
166
On the other hand, if we want to perform differential backups on only some of our databases,
then we will have to create multiple Maintenance Plans, adding some complexity to our
database maintenance. This is because, as we have already learned, the Wizard does not allow
us to include multiple instances of the same task within the same Maintenance Plan. At a
minimum, we will have to create one Maintenance Plan for those databases that don't require
differential backups, and one Maintenance Plan for those databases that do. Alternatively,
we can use the Maintenance Plan Designer, which does allow multiple instances of the same
task, as described in Chapter 16 onwards.
Other parts of the Define Back Up Database (Differential) Task screen are configured in
exactly the same way as the Define Back Up Database (Full) Task screen, so I won't discuss
them again here.
Creating the Job Schedule
If you choose to perform differential backups from within a Maintenance Plan created by the
Wizard, you will have to carefully think through your backup schedule and how you want to
do it. For example, you will have to create a task to perform a full backup once a week (see the
previous chapter on how to do this), a separate task to perform daily differential backups, and
another task to perform transaction log backups (more on this in the next chapter).
What can become a little confusing is how to schedule these three tasks so they don't
interfere with each other. For example, let's assume that we want to perform a full backup
on Sunday, differential backups on Monday through Saturday, and that we want to take
transaction logs once each hour.
To do this, we would need to schedule these three tasks so that the full backup always occurs
first on Sunday night; once a full backup is made, transaction log backups are made once an
hour until Monday night, when the first differential backup is made. Once the Monday night
differential backup is made, then we need to have transaction log backups made every hour
until the Tuesday night differential backup, and so on, until we get back to the Sunday night
full backup.
Scheduling all of these tasks within the Maintenance Plan Wizard is dicult, and if your
schedules overlap, or are in the wrong order, your Maintenance Plan will most likely fail. If

you need to perform differential backups then I think you will find the scheduling process
less of a headache if you use the Maintenance Plan Designer instead, which offers much more
flexibility.
Chapter 13: Back Up Database (Differential) Task
167
Summary
The Maintenance Plan Wizard allows us to create differential backups, but using the Backup
Database (Differential) task, via the Wizard, is not an easy proposition. My first choice
is to avoid differential backups, and to keep my Maintenance Plans as simple as possible. On
the other hand, if you need to create differential backups, then I recommend the use of the
Maintenance Plan Designer, or the use of T-SQL or PowerShell scripts.
168
Chapter 14: Back Up Database
(Transaction Log) Task
Earlier, I stated that the Back Up Database (Full) task is the most important maintenance
task for DBAs to implement. Now we have come to the second most important task,
the backing up of transaction logs, which is implemented using the Back Up Database
Transaction Log) task.
In order to recover as much data as possible after the loss of a database, and to enable
point-in-time recovery of your data, when using the full (or bulk-logged) recovery
model, it is essential that you perform regular transaction log backups in addition to
full backups (Chapter 12), and possibly differential backups (Chapter 13). The Back Up
Database(Transaction Log) task allows you to schedule the backup of your transaction
logs as part of the Maintenance Plan Wizard. This task is not relevant (or available) to any
databases using the simple recovery model, as you cannot back up the transaction log of a
database using this model.
Backing up a database's transaction log offers very important benefits. First of all, it makes a
backup copy of all the transactions that have been recorded in the transaction log file since
the last log backup. These backups, along with any available tail-log backups, help ensure
that, should you have to restore your database, you are able to recover all of the data up until

the point in time that the failure occurred (or very close to it). Essentially, the log backup files
can be applied to a restored copy of a full database backup, and any transactions that occurred
after the full backup will be "rolled forward" to restore the data to a given point in time.
The second important benefit of backing up your transaction log is that it truncates older
data from a database's transaction log, which keeps your transaction log to a reasonable size.
In fact, if you don't backup your transaction log, it can grow until you run out of disk space.
Note, again, that only a transaction log backup, not a full or differential backup, will truncate
a transaction log.
Chapter 14: Back Up Database (Transaction Log) Task
169
An Overview of the Backup Database
(Transaction Log) Task
In order to perform transaction log backups, your databases must use either the full or
the bulk-logged recovery models. If a database is set to the simple recovery model, then
you cannot back up the transaction log, and it will automatically get truncated at regular
intervals, when a database checkpoint occurs. Bear in mind that the master and msdb
databases are set to the simple recovery model (which you should not change) and so you
cannot back up their transaction logs.
A database's transaction log (LDF) file contains a list of entries describing all the actions
performed on the data in that database. A transaction log backup makes a copy of the
recorded actions in this file (the backup copy), which should be stored separately from the
drive on which the live log and data files are stored. Backing up the transaction log generally
results in truncation of the live log file, at which point the previously backed-up entries would
be removed.
Transaction log backups are used in conjunction with full and differential backups to allow
point-in-time recovery of data, in the event of disaster. In fact, it is not possible to perform a
transaction log backup without first performing at least one full backup.
In the event of a disaster, for example a database becoming corrupt, the most current full
backup is restored followed by the subsequent chain of transaction log backups. This
process "rolls forward" the actions recorded in the transaction log backup files. In other

words, it applies them to the full backup in order to rebuild the data as it existed at a certain
point in time.
If the current transaction log is still accessible, which it may not be if, for example, the disk
holding the transaction log has crashed, then the DBA can perform what is called a tail-log
backup, in order to capture any actions recorded in the log that had not previously been
backed up. The tail-log backup can be restored along with all of the other transaction log
backups, minimizing the loss of any data.
Managing backups for databases in the bulk-logged recovery model
In almost all cases, you should use the full recovery model for your databases. The bulk-
logged recovery model is typically only used during times when you are performing bulk
operations. If you are managing backups for bulk-logged databases, then I advise you to
use T-SQL or PowerShell scripts, rather than the Maintenance Plan Wizard, to perform
your database maintenance.
Chapter 14: Back Up Database (Transaction Log) Task
170
When the Backup Database (Transaction Log) task runs using its default settings, it
executes the following T-SQL code (assuming AdventureWorks is being backed up).
BACKUP LOG [AdventureWorks] TO DISK = N'C:\Program
Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\
Backup\AdventureWorks_backup_2009_08_20_111623_3462370.
trn' WITH NOFORMAT, NOINIT, NAME = N'AdventureWorks_back
up_2009_08_20_111623_3462370', SKIP, REWIND, NOUNLOAD, STATS = 10
The BACKUP LOG T-SQL command is similar to the BACKUP DATABASE command, but
produces a transaction log backup file with the extension .TRN, as opposed to .BAK.
The name of the database is used as part of the backup file name, along with an appropriate
date stamp.
When a Backup Database (Transaction Log) task runs, it produces a text report similar to
this one.
Microsoft(R) Server Maintenance Utility (Unicode) Version
10.0.2531

Report was generated on "HAWAII."
Maintenance Plan: User Databases Maintenance Plan
Duration: 00:00:16
Status: Succeeded.
Details:
Back Up Database (Transaction Log) (HAWAII)
Backup Database on Local server connection
Databases: AdventureWorks
Type: Transaction Log
Append existing
Task start: 2009-08-20T11:11:39.
Task end: 2009-08-20T11:11:55.
Success
Command: BACKUP LOG [AdventureWorks] TO DISK = N''C:\
Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\
Backup\AdventureWorks_backup_2009_08_20_111139_2902370.
trn'' WITH NOFORMAT, NOINIT, NAME = N''AdventureWorks_back
up_2009_08_20_111139_2892370'', SKIP, REWIND, NOUNLOAD, STATS =
10
GO
While the above example only shows a single transaction log backup, all the transaction log
backups you select will be shown in your text report.