The Rebuild Index task does a very good job of rebuilding indexes to remove logical fragmentation and empty space, and updating statistics.. • Use the Reorganize Index task followed by t
Trang 1Once 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 offline 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 difficult 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:
Trang 2• 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 difficult 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
Offline Index Maintenance
While it is not a requirement to perform the Rebuild Index task offline, 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
Trang 3degradation 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 offline, 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 offline 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 offline 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
Trang 4Scripting 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
Trang 5Figure 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