Chapter 8: Reorganize Index Task 126 Creating the Job Schedule The last option on the Wizard screen is Schedule which we already know how to use. In our example, we'd run the Reorganize Index task as a direct replacement of the Rebuild Index task, in other words, at 2 a.m. on Sunday morning, during our maintenance window (see Figure 7.10). In general, I recommend you run the Reorganize Index task after the Check Database Integrity task, but before any of the backup tasks. This way you won't waste any time reorganizing your database should the Check Database Integrity task fail. In addition, your backups will be of the latest, reorganized version so, if you have to restore it, it will be ready to use. Once the Reorganize Index task has run, then you want to immediately start the Update Statistics task, so that the databases have properly updated statistics. Don't accidently overlap these tasks, as they will both fight for resources, potentially contributing to performance problems on your SQL Server instance. Summary Like the Rebuild Index task, the Reorganize Index task works to minimize wasted space and logical fragmentation in database indexes. This can help boost the performance of your SQL Server. Think of it as a lightweight alternative to the Rebuild Index task, which is best used when you don't have an available maintenance window to perform the Rebuild Index task. In the next chapter, we take an in-depth look at the Update Statistics task, which is a task you will always want to run after using the Reorganize Index task. 127 Chapter 9: Update Statistics Task The Update Statistics task has been referenced many times in previous chapters, and now it's time to investigate exactly what it does and how it works. When the Update Statistics task is run, it executes the UPDATE STATISTICS command against all of the tables in the databases you select, bringing up to date all index and column statistics. As discussed in Chapter 7, the Rebuild Index task automatically updates statistics and so you should not run the Update Statistics task after running the Rebuild Index task. To do so would, at best, be a waste of server resources and could, if you choose the incorrect configuration options for the Update Statistics task, actually degrade the quality of the statistics available to the query optimizer. Conversely, the Reorganize Index task, discussed in Chapter, does not update statistics and so should immediately be followed by execution of the Update Statistics task. Overview of the Update Statistics Task When a query is submitted to SQL Server, the Query Optimizer attempts to work out the best way to execute that query. It will generate a series of possible execution plans for the query, and assess the predicted overall cost of each plan, in terms of CPU time, I/O, execution time, and so on. The plan with the lowest estimated cost is used to execute the query. This description is an oversimplification of how the Query Optimizer works, but it is adequate for the purposes of this discussion. In order to accurately assess the relative costs of each potential execution plan, the optimizer relies on column and index statistics that are maintained by the SQL Server engine. SQL Server examines the rows of data in the database (or a percentage of those rows – see later) and generates and maintains Statistics objects that provide the Query Optimizer with information such as the size, the number and structure of the tables, the distribution of data values within the table columns, the number of rows that will be returned, the number and structure of available indexes, and index selectivity. Based on these statistics, it decides whether or not indexes can be used, the cost of various types of joins, and so on, and arrives at what it believes is the optimal execution plan. Chapter 9: Update Statistics Task 128 If the statistics available to the query optimizer are out of date or incomplete, then it might create a suboptimal query execution plan, resulting in a poorly performing query. To some extent these statistics are self-maintaining. Column and index statistics are automatically created, and regularly updated, as long as the following two options are turned on for a given database (which they are, by default): • AUTO_CREATE_STATISTICS – used by the optimizer to create statistics on individual columns in the query predicate, as required • AUTO_UPDATE_STATISTICS – the query optimizer automatically updates index and column statistics if it determines that they may be out of date, such as when a data INSERT, UPDATE or DELETE operation changes the data distribution. In most cases, SQL Server does a fairly good job at keeping statistics up to date. However, if you have just performed a database maintenance task, such as reorganizing indexes, then you need to manually update the statistics to ensure that the optimizer has the accurate information it needs to optimize query execution plans. Also, if your SQL Server instance is suffering from poor or erratic performance for certain queries, then you may need to consider manually updating statistics. This is where the Update Statistics task comes into play, although in either case it is generally recommended that you perform these manual updates in addition to leaving AUTO_UPDATE_STATISTICS turned on. Manually Creating Statistics In addition to manually updating statistics, there may also be occasions when you need to create more detailed column statistics than are provided by AUTO_CREATE_ STATISTICS. You can do this using the CREATE STATISTICS command. This task is not covered by the Maintenance Plan Wizard and is outside the scope of this book. More information can be found in Books Online. When the Update Statistics task runs using its default settings, the following T-SQL code is executed on every table in every selected database. UPDATE STATISTICS table_name WITH FULLSCAN We will discuss the FULLSCAN option a little later in this chapter, but basically it means that the optimizer will check every row of every table in order to ensure that the index and column statistics are as accurate as possible. Chapter 9: Update Statistics Task 129 When you execute this task, it produces a text report similar to this: Microsoft(R) Server Maintenance Utility (Unicode) Version 10.0.2531 Report was generated on "HAWAII." Maintenance Plan: MaintenancePlan Duration: 00:00:07 Status: Succeeded. Details: Update Statistics (HAWAII) Update Statistics on Local server connection Databases: AdventureWorks Object: Tables and views All existing statistics Task start: 2009-07-30T15:25:13. Task end: 2009-07-30T15:25:19. Success Command:use [AdventureWorks] GO UPDATE STATISTICS [dbo].[AWBuildVersion] WITH FULLSCAN GO use [AdventureWorks]| GO UPDATE STATISTICS [dbo].[DatabaseLog] WITH FULLSCAN GO While the above is an abbreviated report, yours will show the UPDATE STATISTICS command run for every table in your selected databases. If there are any problems or error messages, you will see them here also. When and How Often to Update Statistics Running the Update Statistics task is an online procedure and generally doesn't have much negative impact on a server's performance, especially for smaller servers with low numbers of users. However, bear in mind that your cached query plans reference your existing Statistics objects. What this means is that, when you update those Statistics objects, the plans that reference them will need to be recompiled, which could be an expensive operations terms of server resources. If you're updating the statistics too Chapter 9: Update Statistics Task 130 frequently, you can cause unnecessary recompiles and negatively affect performance, especially if your databases are large and user numbers high. Statistics sampling If your databases are large, you may consider configuring the task to sample only a percentage of the rows in the database, in order to reduce the burden on the server. The downside is that this reduces the accuracy of the statistics. This is discussed in more detail shortly, in the section on the Scan type option. With this in mind, here is my general advice with regard to when and how often to run the Update Statistics task. • Never, if you are running frequent (e.g. nightly) index rebuilds. The Rebuild Index task automatically performs a full scan statistics update of all indexes and columns. • Immediately after the Index Reorganization task. So if you run the Index Reorganize task in a nightly maintenance window, you will also run a nightly Update Statistics task. • On days when you don't run the Rebuild Index or the Reorganize Index task. See why below. Here's something to consider. Let's say that your maintenance window only allows you to perform a weekly Rebuild Index task, or a Reorganize Index task followed by an Update Statistics task. When using this particular scheduling, you may discover that query performance among some of your databases is uneven. In other words, sometimes a particular query runs very fast, and other times it runs very slowly. While there are many possible causes for this, the problem may be caused by, or exacerbated by, incomplete or out of date statistics. Assuming that you have determined that outdated or incomplete statistics are causing the erratic performance behavior of some queries, one way to help prevent this problem is to run the Update Statistics task on those nights when you are not running the Rebuild Index task or the Reorganize Index task. Doing so can help to ensure that your databases' index and columns statistics are up to date, helping to optimize query performance. . performance of your SQL Server. Think of it as a lightweight alternative to the Rebuild Index task, which is best used when you don't have an available maintenance window to perform the Rebuild. task. Overview of the Update Statistics Task When a query is submitted to SQL Server, the Query Optimizer attempts to work out the best way to execute that query. It will generate a series of possible. cases, SQL Server does a fairly good job at keeping statistics up to date. However, if you have just performed a database maintenance task, such as reorganizing indexes, then you need to manually