Brad’s Sure Guide to SQL Server Maintenance Plans- P22 potx

Chapter 7: Rebuild Index Task 106 Once the header information is displayed, note that the command executes for each index in the database. I have abbreviated the report to only show two indexes being rebuilt, as there were a lot more that were actually rebuilt in the full report. When and How Often to Rebuild Indexes The performance of your indexes, and therefore your database queries, will degrade as you indexes become fragmented. The Rebuild Index task does a very good job of rebuilding indexes to remove logical fragmentation and empty space, and updating statistics. As such, it is very important that you schedule this task to run regularly. On the other hand, the Rebuild Index task is resource intensive. In addition, as an index is being rebuilt, locks will be placed on it, preventing anyone from accessing it while the rebuilding occurs. Any queries trying to access this index in order to return the required results will be temporarily blocked, until the rebuild is complete. As such, the Rebuild Index task is considered an oine activity, to be run when as few people as possible are accessing a database. In general, this means during a scheduled maintenance window. It is quite dicult to offer general advice with regard to when and how often to rebuild indexes using the Maintenance Plan Wizard, as it is so dependent on the nature of the data, the indexes and the queries that use them. However, take a look at my general advice with regard to index rebuilding, and then we'll consider the advice in a little more detail over the coming sections. • Nightly, if required. If your indexes fragment rapidly, and you have a nightly mainte- nance window that allows you to run the Rebuild Index task, along with all the other maintenance tasks, then do so. Index fragmentation will degrade the performance of your indexes. Assuming that you have a maintenance window, rebuilding every night can't do any harm, and can very well boost the performance of your server. • Weekly, at minimum. If you can't perform this task nightly, then, at a minimum, it should be run once a week, during a maintenance window. If you wait much longer than a week, you risk hurting your SQL Server's performance due to the negative impact of wasted empty space and logical fragmentation. • Consider alternatives, otherwise. If you don't have a maintenance window long enough to run this task at least once a week, then you need to consider the following alternatives: Chapter 7: Rebuild Index Task 107 • Use the online version of the Rebuild Index task – available only with the Enterprise Edition of SQL Server. • Use the Reorganize Index task followed by the Update Statistics task – if you're using the Standard Edition of SQL Server. This is your only real alternative when using the Maintenance Plan Wizard if want to avoid the Rebuild Index task. • Avoid the Maintenance Plan Wizard – T-SQL or PowerShell scripts offer greater control and flexibility over the exact nature and duration of this task. Tracking Index Fragmentation The question of exactly how often to rebuild indexes is a dicult one to answer, and the Maintenance Plan Wizard doesn't offer any guidance. The speed and degree to which an index fragments depends on how it is used, and will vary wildly from database to database. It is beyond the scope of this book to enter a full discussion of measuring index fragmentation, and therefore deciding how often you should rebuild your database's indexes. However, it is worth noting that the sys.dm_db_index_physical_stats Dynamic Management Function contains two columns that store valuable information regarding index fragmentation: • avg_page_space_used_in_percent – this column stores the average amount of space that is used on a page. For example, a particular index might have 50% space used, which means that, on average, only half of the space on a data pageis used to store rows of data. • avg_fragmentation_in_percent – this column stores the degree of logical fragmenta- tion of an index, as a percentage. For example, a particular index might be 80% frag- mented, which means that, on average, 80% of the data pages physical ordering does not match their logical ordering. If you were to track this data over a period of time, you would be better able to gauge how quickly your indexes fragment, and so how often you should consider rebuilding them. However, if you are at this level, then the chances are high that you'll be using scripting techniques to rebuild your indexes rather than the Maintenance Plan Wizard. Oine Index Maintenance While it is not a requirement to perform the Rebuild Index task oine, while the database is not being accessed, it is certainly a strong recommendation, especially for large databases with many users. If your tables are relatively small, rebuilding will be fast and most users who happen to be accessing the database at the same time probably won't notice any performance Chapter 7: Rebuild Index Task 108 degradation as a result of the locking required by Rebuild Index task. On the other hand, if your tables are big, or if you have lots of concurrent users, the Rebuild Index task can negatively affect your users' experience, greatly slowing down their access to the database, and potentially causing some queries to time out from their client application. Generally speaking, if you have a large enough maintenance window to accommodate running your Rebuild Index task oine, then I recommend you use this task, and run it during that window. Online Index Maintenance If you don't have a maintenance window, or it is not long enough to accommodate an oine Rebuild Index task, then you have one or two possible alternatives available to you, when using the Maintenance Plan Wizard: • use the online version of the Rebuild Index task • use the Reorganize Index task followed by the Update Statistics task. If you have the Enterprise Edition of SQL Server, the Maintenance Plan Wizard offers a Keep index online while reindexing option, which means that the index will continue to be available to users even while it is being rebuilt. Even though this is an online activity, you will still want to schedule this task during a time of the day when the server is less busy, as it is still a resource-intensive activity. Performing this online task during busy times of the day can affect your users' ability to access the database in a timely manner, especially if your SQL Server already has performance bottlenecks. If you don't have the Enterprise Edition, and your maintenance window is too short to accommodate an oine Rebuild Index task, then you should consider using the Reorganize Index task (see Chapter 8) instead, and running the Update Statistics task (see Chapter 9) immediately thereafter. The Reorganize Index task is an online operation, which means that it can run while users are accessing the database. While this is an online process, it is still resource intensive, and you should schedule the task during a time of the day when the server is less busy. The downside to using the Reorganize Index task is that its index defragmentation capability is not as thorough and complete as the Rebuild Index task. In addition, it can take longer to run than the Rebuild Index task, and you have to run the Update Statistics task as a separate step. Chapter 7: Rebuild Index Task 109 Scripting Index Rebuilds If you have the Enterprise Edition of SQL Server, chances are that your databases may be very large, and using the Maintenance Plan Wizard to maintain your databases may not be a great choice in the first place. You can obtain more flexibility and control by creating your own custom maintenance plans using T-SQL or PowerShell scripts. For example, you can measure and track fragmentation using sys.dm_db_index_physical_ stats and then build a script to defragment only those indexes that really need it. Configuring the Rebuild Index Task Now that we know a little about the Rebuild Index task, and when it should be run, let's look at its configuration screen from the Maintenance Plan Wizard, shown in Figure 7.1. Our first choice is to select which databases we want to run this task against. We have already covered the various options in detail, in Chapter 3, so here we'll just focus on specific considerations for this task. Database Selection First, notice the Databases drop-down box appears on the screen as we have seen before. Second, notice that directly below the Databases drop-down box are two more drop-down boxes we have not seen before: Object and Selection. These two drop-down boxes appear for some tasks, and not others. We will see what they do in a moment; I just wanted to point them out now so you will be ready when I begin talking about them. Selecting Several Databases As a general rule, you want to keep the number of separate Maintenance Plans to a minimum so, ideally, you'd create a single plan and apply the Rebuild Index task to all indexes in a given set of databases, for example in all user databases. Also, in order to ease maintenance and avoid confusion, each task in the plan should be applied to the same set of databases. Chapter 7: Rebuild Index Task 110 Figure 7.1: We are ready to configure the "Rebuild Index" task. However, there may be special cases where you'd need to create separate plans to deal with the specific index maintenance requirements of different databases. For example, let's assume that on a single SQL Server instance you have 25 small databases, each less than 1 GB in size, and one large database, say, 50 GB. Let's also assume that few, if any, users will need access to the small databases during your maintenance windows, but that many users may need to access the 50 GB database during this time. In this case, you might consider creating a special Maintenance Plan for the 50 GB database that uses the Reorganize Index and Update Statistics tasks, and another Maintenance Plan that applies the Rebuild Index task to the smaller databases. . general, this means during a scheduled maintenance window. It is quite dicult to offer general advice with regard to when and how often to rebuild indexes using the Maintenance Plan Wizard, as it is. ability to access the database in a timely manner, especially if your SQL Server already has performance bottlenecks. If you don't have the Enterprise Edition, and your maintenance window is too. your own custom maintenance plans using T -SQL or PowerShell scripts. For example, you can measure and track fragmentation using sys.dm_db_index_physical_ stats and then build a script to defragment