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

Chapter 19: Playing Administrator
aware, however, that there are more robust options available for the more advanced user that can allow
you to programmatically control many of the administration features via the SQL Server Management
Objects (SMO) object model.
Scheduling Jobs
564
Many of the tasks that we’ll go over in the remainder of the chapter can be scheduled. Scheduling jobs
allows you to run tasks that place a load on the system at off-peak hours. It also ensures that you don’t
forget to take care of things. From index rebuilds to backups, you’ll hear of horror stories over and over
about shops that “forgot” to do that, or thought they had set up a scheduled job but never checked on it.
If your background is in Windows Server, and you have scheduled other jobs using the Windows Scheduler
service, you could utilize that scheduling engine to support SQL Server. Doing things all in the
Windows Scheduler allows you to have everything in one place, but SQL Server has some more robust
branching options.
There are basically two terms to think about: Jobs and Tasks.
❑ Tasks: These are single processes that are to be executed or a batch of commands that are to be
run. Tasks are not independent. They exist only as members of jobs.
❑ Jobs: These are a grouping of one or more tasks that should be run together. You can, however,
set up dependencies and branching depending on the success or failure of individual tasks. (For
example, Task A runs if the previous task succeeds, but Task B runs if the previous task fails.)
Jobs can be scheduled based on the following criteria:
❑ Daily, weekly, or monthly basis
❑ A specific time of the day
❑ A specific frequency (say, every 10 minutes, or every hour)
❑ When the CPU becomes idle for a period of time
❑ When the SQL Server Agent starts
❑ In response to an alert
Tasks are run by virtue of being part of a job and based on the branching rules you define for your job.
Just because a job runs doesn’t mean that all the tasks that are part of that job will run; some may be executed
and others not depending on the success or failure of previous tasks in the job and what branching
rules you have established. SQL Server not only allows one task to fire automatically when another finishes,
it also allows for doing something entirely different (such as running some sort of recovery task) if
the current task fails.
In addition to branching you can, depending on what happens, also tell SQL Server to perform the following:
❑ Provide notification of the success or failure of a job to an operator. You’re allowed to send a
separate notification for a network message (which would pop up on a user’s screen as long as
they are logged in), a pager, and an e-mail address to one operator each.