Beginning Microsoft SQL Server 2008 ... - S3 Tech Training

Chapter 19: Playing Administrator
Schedule
With all this setup, wouldn’t it be nice to set up a job to run this backup on a regular basis? Well, the
Script button up at the top of the dialog box provides a means to do just that. Click it, and you’ll get a
list of options. Choose “Script Action to Job…” and it will bring up the Job Schedule dialog box we saw
earlier in the chapter, but with the job steps already completed. You can then define a regular schedule to
run the backup you just defined by selecting the Schedules tab and filling it out as you desire.
Recovery Models
578
Note that there are several more options for backups that are only addressable via
issuing actual T-SQL commands or using the .NET programmability object model
SMO. These are fairly advanced use, and further coverage of them can be found in
Profession SQL Server 2008 Programming.
Well, I spent most of the last section promising that we would discuss them, so it’s time to ask: What is a
recovery model?
Well, back in our chapter on transactions (see Chapter 14), we talked about the transaction log. In addition
to keeping track of transactions to deal with transaction rollback and atomicity of data, transaction
logs are also critical to being able to recover data right up to the point of system failure.
Imagine for a moment that you're running a bank. Let's say you've been taking deposits and withdrawals
for the last six hours — the time since your last full backup was done. Now, if your system went down,
I’m guessing you’re not going to like the idea of going to last night’s backup and losing track of all the
money that went out the door or came in during the interim. See where I’m going here? You really need
every moment’s worth of data.
Keeping the transaction log around gives us the ability to “roll forward” any transactions that happened
since the last full or differential backup was done. Assuming both the data backup and the transaction
logs are available, you should be able to recover right up to the point of failure.
The recovery model determines for how long and what type of log records are kept; there are three
options:
❑ Full: This is what it says; everything is logged. Under this model, you should have no data loss
in the event of system failure assuming you had a backup of the data available and have all
transaction logs since that backup. If you are missing a log or have one that is damaged, then
you’ll be able to recover all data up through the last intact log you have available. Keep in mind,
however, that as keeping everything suggests, this can take up a fair amount of space in a system
that receives a lot of changes or new data.
❑ Bulk-Logged: This is like “full recovery light.” Under this option, regular transactions are
logged just as they are with the full recovery method, but bulk operations are not. The result is
that, in the event of system failure, a restored backup will contain any changes to data pages
that did not participate in bulk operations (bulk import of data or index creation, for example),
but any bulk operations must be redone. The good news on this one is that bulk operations perform
much better. This performance comes with risk attached, so your mileage may vary.