Brad’s Sure Guide to SQL Server Maintenance Plans- P16 docx

A word of warning before we move on: while it's possible to customize your Maintenance Plan by directly modifying its SQL Server Agent jobs, I strongly advise against it.. Chapter 3: Get

You can double-click on each job to open it up and see what it looks like While I don't recommend you make any changes, it is interesting to look at the command used to execute the SSIS package for a particular scheduled task, as shown in Figure 3.21

Figure 3.21: This screen shows how the SSIS package will be executed for this

maintenance task.

As you can see in this figure, when a scheduled job executes, all it does is execute the related SSIS package, with a number of parameters that specify the plan to be run, the server it is to

be run on, and so on In this particular example, Subplan_1 of the Maintenance Plan is being run and so is passed in as a parameter

A word of warning before we move on: while it's possible to customize your Maintenance Plan by directly modifying its SQL Server Agent jobs, I strongly advise against it Unless you are an expert in both SSIS and the SQL Server Agent, the odds of "breaking" the Maintenance

Chapter 3: Getting Started with the Maintenance Plan Wizard

Likewise, if you want to delete a Maintenance Plan, be sure you do so right-clicking on the Maintenance Plan's name and clicking Delete If you try to delete the Maintenance Plan's SSIS package or SQL Server Agent jobs directly, you could create a mess that will be difficult

to untangle

Generally speaking, if you feel you need to do a lot of customization to a Maintenance Plan once it has been created, then most likely you would be better off using T-SQL or PowerShell scripts for your database maintenance

Testing Your Maintenance Plan

Having created a new Maintenance Plan, and before congratulating ourselves on a job well done and going home for the night, we should first test it to see if it runs as we expect

To test our new Maintenance Plan, we need to run it against SQL Server, preferably during

a maintenance window so that any resources used by the plan do not interfere with user activity So what's the best way to test a Maintenance Plan? At first glance, this seems easy We can simply right-click on the plan and select Execute, as shown in Figure 3.22

Figure 3.22: Does selecting "Execute" actually execute a Maintenance Plan?

Sounds straightforward enough but, when we select Execute, we get the error message shown in Figure 3.23

Figure 3.23: Apparently, selecting "Execute" is not a good way to test a Maintenance Plan.

What does this error mean? Is our Maintenance Plan "bad?" In order to answer this question,

we can click on the Execution failed… link to find out more information about this error, as shown in Figure 3.24

Figure 3.24: Unlike most error messages, this one is actually useful.

The error message is actually useful in this case: "User Databases Maintenance Plan contains multiple subplans You can execute them individually by selecting their associated jobs under the SQL Server Agent node of Object Explorer."

In other words, the Execute option available for a Maintenance Plan will only work if a

Chapter 3: Getting Started with the Maintenance Plan Wizard

one subplan (and most do), then you have to execute the individual SQL Server job for each

of the subplans in your Maintenance Plan When creating our example Maintenance Plan using the Wizard, behind the scenes this was actually implemented as six individual

subplans, one for each of the tasks we configured So, in order to fully test our plan, we will need to manually execute each of the six subplans of the Maintenance Plan in the correct logical order

Maintenance Task Order

As discussed in the earlier section on Maintenance Task Order, some jobs have to run

before other jobs, otherwise they might fail.

So, in order to test our new plan, we navigate to the SQL Server Agent | Jobs directory, right-click on the relevant Maintenance Plan Job and select Start Job at Step , as shown in Figure 3.25

Although this name gives the impression that it might allow us to run all of the jobs, it doesn't Instead, once we select this option, only the job we have selected will run Why is this? This is because a "step" is a subset of a job, and all Maintenance Plan jobs have a single

"step." The confusion arises because "step" and "job" sound like the same thing, but they aren't Each job only has a single step, so we must test each job, one after another

Having run the first job, we run the second, and so on, until they have all completed Be sure

to only run one job at a time, and wait for it to complete successfully before trying the next

If the databases against which the plan is running are large, then these tests can be time consuming, so this extra time must be planned for in advance In fact, the time it takes for a particular task to run during testing is a valuable data point when determining when the task should be scheduled to run

Maintenance Task Scheduling…

…is covered in full detail in Chapter 4, where you will learn that determining the length

of a task is a very important part of creating maintenance task schedules.

Figure 3.25: You can test each maintenance task by running Start Job at Step

While all this sounds like a somewhat laborious process, this testing is essential to ensure that your Maintenance Plan, as a whole, will succeed Furthermore, if a given job fails, you have immediately narrowed your troubleshooting to the investigation of an individual job, rather than the plan as a whole

Let's go ahead and run the first job in our Maintenance Plan, the Check Database

Integrity job, and see what happens Right-click on User Databases Maintenance Plan Subplan1, and select Start Job at Step Hopefully, you'll see a screen similar to that shown in

Figure 3.26