Configuring the Backup Database Transaction Log Task Now that we have a little background on transaction logs, let's take a look at how to use the Define Back Up Database Transaction Lo
Trang 1When and How Often to Back Up
Transaction Logs
Generally speaking, you want to back up your transaction logs often enough so that you are at minimal risk of losing data (you can't always count on being able to do a tail-log backup), and that the transaction log is kept down to a reasonable size (because backing up the transaction log truncates the transaction log)
The more frequently you take log backups, the smaller is your organization's exposure to the risk of potential data loss On the downside, the more transaction log backups you take, the more administrative effort it requires, and the more server resources are used
While there is no perfect transaction log backup interval, taking transaction log backups on
an hourly basis is a fairly good compromise Of course, if you can't afford to lose an hour's worth of data, and/or your server is very busy and causes the transaction log to grow quickly, then you may want to perform transaction logs more often, perhaps every 15 minutes or so
If you can't decide what transaction log backup interval to choose, I would err on having too many over having too few
Of course, some organizations have policies that determine how much data they are willing
to risk losing, and this will directly affect how often you perform transaction log backups
If your company doesn't have such a policy, then you might want to bring this issue to management, along with the pros and cons, and allow them to determine how much data they are willing to risk losing
Configuring the Backup Database
(Transaction Log) Task
Now that we have a little background on transaction logs, let's take a look at how to use the
Define Back Up Database (Transaction Log) Task screen, shown in Figure 14.1.
Trang 2Chapter 14: Back Up Database (Transaction Log) Task
Figure 14.1: Configuring transaction log backups is almost identical to configuring
full backups.
Trang 3At the top of the screen, the Backup type option is set to Transaction Log and is grayed out
As you can see, after that, this screen of the wizard is virtually identical to the screen for full and differential backups, so it will only be described briefly in this chapter Please refer to Chapter 12 for full details
The first step, as always, is to select the databases on which you wish to perform transaction log backups I highly recommend that you select the same databases in this screen as you did when you created the Back Up Database (Full) task While it is possible to create two separate Maintenance Plans, one to do only full backups and one to do only transaction log backups, it would be a lot of extra work for no benefit
One difference that you'll notice on the Database Selection screen is that the System databases option is grayed out, and that under These databases you will only see those
databases that are using the full or bulk-load recovery models, since you can't perform transaction log backups on databases that use the simple recovery model
Use separate Maintenance Plans for system and user databases
Most SQL Server instances are likely to have some user databases that use the full
recovery model, alongside system databases, and other user databases, which use the
simple recovery model While you can create a single Maintenance Plan to cover all
these databases, I prefer to create two separate Maintenance Plans, one for the system databases and one for the user databases, with each plan tailored to the specific
maintenance needs of each set of databases
Under Backup to you will want to choose disk, and under Create a backup file for every database you should specify the same settings as you did for your full backups This way, your
full backups and log backups will be stored in the same location In addition, leave the backup file extension to TRN, which is the default extension used for transaction log backups, and select Verify backup integrity, just as you should with all backups If you have the Enterprise
Edition of SQL Server, set the backup compression settings to the same as you did for your full backups
Backing Up the Tail of the Log
One setting that is available on this screen, but is grayed out on the full backup and
differential backup screens, is Back up the tail of the log, and leave the database in the restoring state Do not select this option, as it won't work as part of a Maintenance Plan
The reason you see it is because this screen shares code with other parts of SSMS, and it
is only from within SSMS that you might use this option to make a tail-log backup when recovering from a damaged database
Trang 4Chapter 14: Back Up Database (Transaction Log) Task
Creating the Job Schedule
The last step is setting the schedule for this task The schedule screen is the same one we have seen many times before, so we don't have to examine it again Just set the schedule so that transaction log backups occur on the schedule that you determine is best for your SQL Server environment As I recommended earlier, I schedule transaction log backups at least once an hour, if not more often You also need to keep in mind that you must perform at least one full backup of a database before you can perform a transaction log backup Therefore, be sure that your full database backup schedule is set to start before your transaction log backup schedule
If a scheduled transaction log backup is due to start while a full backup is occurring, then the transaction log backup job will wait until the full backup is done, and then it will run
Summary
We have learned that the Back Up Database (Transaction Log) task is the second most important maintenance task that can be performed with the Maintenance Wizard, as it minimizes an organization's exposure to data loss, and truncates older data from a database's transaction log, which keeps your transaction log file to a reasonable size
We are now done discussing the three backup maintenance tasks, and next, we will learn how
to run the Maintenance Cleanup task, which can be used to help us remove old backup files
Trang 5Cleanup Task
This chapter completes our run through each of the tasks available through the Maintenance Plan Wizard and, perhaps fittingly, is where we clean up after ourselves
If you run regular Backup Database tasks (full, differential, and transaction log) as part of the Maintenance Plans you create using the Maintenance Plan Wizard, then you may find that a lot of backup files are being stored on the local server, and this can very quickly eat up a lot of disk space
In addition, if your Maintenance Plans write a report each time any maintenance task is executed, as I recommended in Chapter 3, then a text file will be created and stored each time While these text files are generally small, many hundreds of them can be created each week and they can quickly take up a surprising amount of disk space
Unless you regularly clear out older backup and text files, you could run out of disk space, bringing SQL Server to a grinding halt Perhaps you have an Execute SQL Server Agent Job task that will warn you before you get to that point but, in any event, you must create some sort of plan to remove older files from your disk subsystem on a regular basis This plan can
be implemented using the Maintenance Cleanup task and this chapter will describe how the task works, and how to configure and schedule it using the Wizard
Unfortunately, the Maintenance Plan Wizard implements the task in a somewhat
compromised manner, allowing you to only remove one type of file (BAK, TRN or TXT) at a time, within a given Maintenance Plan As such, we'll discuss ways around this limitation, including use of the Designer (see Chapter 16 onwards)
An Overview of the Maintenance
Cleanup Task
An important part of every DBA's job is to determine a strategy for database backup storage While you may be making backups to a local drive, this is not where you want them stored long term If you store backups on the live server and the server suffers disk failure, then you could lose both the live databases and the backups As such, it is important for the DBA
to create a system whereby database backups are copied off the original SQL Server and stored in a safe location, preferably offsite Ideally, you should be copying backups from your