The Define Update Statistics Task screen in the Maintenance Plan Wizard is shown in Figure 9.1.. The first part of the Define Update Statistics Task screen looks similar to the Rebuild
Trang 1Configuring the Update Statistics Task
Now that we know what the Update Statistics task does, let's learn how to configure
it The Define Update Statistics Task screen in the Maintenance Plan Wizard is shown in
Figure 9.1
Figure 9.1: The Update Statistics Task screen has both familiar and unfamiliar
configuration options.
The first part of the Define Update Statistics Task screen looks similar to the Rebuild Index Task and the Reorganize Index Task screens.
Trang 2Chapter 9: Update Statistics Task
Database Selection
The options here, with the Databases, Object and Selection drop-down boxes, are the same
as those described in the equivalent section of Rebuild Index chapter (Chapter 7), so I will not
explain them again here On the whole, I recommend you don't use the Object and Selection
options for this task If you need this kind of granularity in your Maintenance Plan, then you should be using T-SQL or PowerShell scripts instead
If you are using the Reorganize Index task as part of your Maintenance Plan, then you should select the same databases here as you selected for the Reorganize Index task As discussed previously, any database that is reorganized needs to have its statistics updated
If you are creating a special Maintenance Plan that will only run the Update Statistics task (for example, on the days that you aren't running the Reorganize Index task or the Rebuild Index task), then you will most likely want to select all your user databases
Once you have selected your databases, the Update and Scan type options become available,
as shown in Figure 9.2
Let’s take a look at each option in turn
The Update Option
The Update option allows you to specify which types of statistics are to be updated The
options are fairly self-explanatory
• All existing statistics – both column and index statistics are updated.
• Column statistics only – only updates column statistics.
• Index statistics only – only updates index statistics.
The default is All existing statistics and is the correct choice in almost all cases, as both types
of statistics need to be updated if you want the query optimizer to have all the data it needs to create optimal query plans
The only reason you might want to choose either of the other options is if you want to reduce the amount of time this job takes to execute However, by doing this, you increase the risk that your query execution plans may be less than ideal
Trang 3Figure 9.2: The default options under "Update" and "Scan type" should stay selected.
The Scan type Option
The Scan type option allows you to specify how exhaustive a job the Update Statistics task does In order to do the most thorough job, and produce the most complete set of statistics, SQL Server will need to example every single row in every table on which the task is being run This is what happens when you select the default option of Full scan.
The alternative is to select the Sample by option, and specify the percentage of rows that
should be sampled in order to update the statistics This option is faster, and requires fewer server resources, but may produce statistics that are incomplete or inaccurate, causing some queries to perform less than optimally
The hard part is in determining which option to choose If there is a wide distribution of data
in a given database, then the optimizer will need to sample all or most of the rows in order to generate accurate statistics If the data in the rows varies little, then sampling only some of
Trang 4Chapter 9: Update Statistics Task
If you're using T-SQL or PowerShell scripts, you can work this out on a table-by-table basis and configure your scripts appropriately However, since we're using the Maintenance Plan Wizard and are striving for simplicity, we have to compromise
My recommendation is to use the Full Scan option whenever you run the Update
Statistics task, except perhaps in those cases where your databases are very large If your databases are large, and if using the Full Scan option causes performance problems
because of the resources needed to perform the Full Scan, then use a Sample by scan to
reduce the time and resources it takes to perform this task Start out at 50%, and see how much you save in time and resources, and how reducing the sampling rate affects query performance You may have to conduct several experiments to find the idea sample rate to best meet your needs
Creating the Job Schedule
The last option to configure is the job schedule As discussed previously, you should generally only schedule the Update Statistics task if you run the Reorganize Index task, and you should run one immediately after the other, but not overlap the two jobs The exception to this is if you only rebuild or reorganize indexes once a week and you want update statistics on the nights when the indexes aren't being rebuilt or reorganized
In our example, we want to run the Update Statistics task immediately after the
Reorganize Index task, which takes place at 2 a.m on Sunday, during our maintenance window (see Figure 7.10) So, depending on how long the Reorganize Index task takes, we may decide to schedule the Update Statistics task for, say, 4 a.m as our best guess, and then adjust it accordingly, once we learn how long the Reorganize Index task really takes
Summary
In theory, index and column statistics should update themselves but, as we have seen in this chapter, this is not always the case For example, if we run the Reorganize Index task, we need to manually update statistics Or, under some circumstances, where statistics become out of date sooner than expected, causing some queries to perform erratically, we may need
to run the Reorganize Index task more often If you don't have a good understanding of how statistics work, it is worth your while to learn more about them, as they play a large part
in how well your SQL Server instance performs
In the next chapter, we learn about the Execute SQL Server Agent Job task, which allows
us to run a job from within a Maintenance Plan
Trang 5Agent Job Task
The Execute SQL Server Agent Job task does exactly what it says: it allows you to run one (and only one) predefined SQL Server Agent job as part of a Maintenance Plan created with the Maintenance Plan Wizard
Why would you want to run a SQL Server Agent job as part of a Maintenance Plan? In most cases, you probably wouldn't As I have mentioned before, the biggest benefit of using the Maintenance Plan Wizard is simplicity, and if its simple maintenance model doesn't work for your environment, then you are probably often better off using T-SQL or PowerShell scripts
to perform maintenance tasks, as they are more powerful and flexible than what a single SQL Server Agent job can do for you
However, if you happen to want to run a single, simple SQL Server Agent job as part of your Maintenance Plan, it is something that you can do For example, you might want to run a nightly job to check how much disk space is left on your drives and, if the amount is less than 20%, to have the job send you a warning message
An Overview of the Execute SQL
Server Agent Job Task
SQL Server Agent is a Windows service that you can use to execute scheduled maintenance tasks, which are called jobs As we discussed in Chapter 3, when you create a Maintenance
Plan using the wizard, SQL Server implements it as an SSIS package and, under the covers, creates the number of SQL Server Agent jobs required run the tasks in the plan
In addition to the ten defined tasks that the Wizard allows you to configure and schedule, the Execute SQL Server Agent Job allows you to add one additional "custom" maintenance task
to a given Maintenance Plan This custom task is defined as part of the Agent job, not in the Wizard, so in effect all you are doing is adding a predefined job to the plan, and scheduling when it should run
The nature of this task depends entirely on the nature of the predefined SQL Server Agent job, and these jobs can be used to perform many different tasks