In the Rebuild Index task, "default amount of free space" refers to the fill factor that was used when a specific index was first built, or last rebuilt.. In other words, if you choose t
Trang 1issues because it results in index fragmentation, the very thing we are trying to eliminate with the Rebuild Index task In order to mitigate this problem, DBAs often decrease the fill factor
to perhaps 90, meaning that data pages will be 90% full, leaving 10% free space
For more information regarding fill factors and page splitting…
…refer to Books Online A full discussion of these topics is beyond the scope of this book, but I needed to include a little background so you could better understand what is
happening when you make particular selections within the Wizard Also, don't assume that my example of a fill factor of 90 is appropriate for your indexes It may be, or it may not be.
What is really confusing is that the phrase "default amount of free space" in the Wizard does not mean the same thing as the "default fill factor" that can be set for the entire server Some people confuse the two
In the Rebuild Index task, "default amount of free space" refers to the fill factor that was used when a specific index was first built, or last rebuilt In other words, if you choose the option Reorganize pages with the default amount of free space, what happens is that each index is rebuilt using whatever fill factor value was used the last time it was rebuilt This may
be the same as the server-wide default, or it may be a specific value that was specified for that index, or it may be a value set using the second Change free space per page percentage to option (discussed next)
In almost all cases the "default amount of free space" option is the one you want to use, as
it means the index will be rebuilt using the fill factor that was originally specified when the index was created
With the second option, Change free space per page percentage to, you specify a single fill factor value to be used for every index when it is rebuilt For example, if you choose Change
free space per page percentage to and set it to 10%, this is the same thing as setting all of
the indexes in your database to a fill factor of 90, regardless of what the value was when the index was created It is rarely a good idea for every index in your database to have the same fill factor The appropriate fill factor is specific to an index, and you can't generalize a fill factor that will work well for every index in your database While this setting might be beneficial for some indexes, it could cause performance problems with others As a result, I advise against using this option
Trang 2Chapter 7: Rebuild Index Task
Advanced options
The two options under Advanced options are shown in Figure 7.9
Figure 7.9: The Advanced options section of the Define Rebuild Index Task screen
By default, both options are turned off The first one is Sort results in tempdb If you don't choose this option then, when an index is rebuilt, all of the rebuilding activity is performed
in the database file itself If you select the Sort results in tempdb option, then some of the activity is still performed in the database, but some of it is also performed in tempdb The benefit is that this can often speed up the index rebuild process The drawback is that it also takes up a little more overall disk space, as space in tempdb is required, in addition to some space in the database where the indexes are being rebuilt
The benefit you get out of this option depends on where tempdb is located on your server
If tempdb is located on the same drive or array as the database file that is having its
indexes rebuilt, then the benefit may be minimal, if any However, if tempdb is located
on its own isolated drive spindles, then the benefit will be greater because there is less disk I/O contention
So, should you use this option? If your databases are small, you probably won't be able to discern much performance benefit, but if you have large databases, with large tables and indexes, and if tempdb is located on its own spindles, then turning this feature on will probably boost index rebuild performance
The second advanced option is one we've discussed previously: Keep index online while
reindexing This option is only available if you have the Enterprise Edition of SQL Server By
selecting this option, index rebuilding becomes an online, rather than offline task If you are using Enterprise Edition, you will probably want to select this option I say "probably" because there are pros and cons to performing an online index rebuild – a topic that is beyond the scope of this book
Trang 3Creating the Job Schedule
As always, our final step is to define an appropriate schedule on which to run our Rebuild Index job With the previous advice in mind, the best option would be to run the job within
a nightly maintenance window However, in Chapter 3, I stated that my assumption for all
my examples was that I have a single weekly maintenance window, which is the entire day
of Sunday
Therefore, let's schedule the Rebuild Index task to occur on Sunday, right after the Check Database Integrity task completes As such, the screen will look as shown in Figure 7.10
Figure 7.10: The schedule for the Rebuild Index job.
Trang 4Chapter 7: Rebuild Index Task
Since this is a new Maintenance Plan, we don't have any experience with regard to how long each task runs yet, and so we have to guess In this example, I'll guess that the first Check Database Integrity task will take an hour, starting at 1 a.m., so I will schedule the Rebuild Index task to start at 2 a.m If I'm wrong, the two jobs will overlap, which could cause some performance problems
As a DBA, the first time you run any Maintenance Plan, you need to check how long each job takes to run, as described in the "Avoid Overlapping Tasks" section of Chapter 4 If your guess
is wrong, and jobs overlap, you can use the Maintenance Plan Designer (see Chapters 16–19)
to alter the schedule for the next time it runs
I recommend that you run the Rebuild Index task before any of the backup tasks (discussed
in Chapters 12, 13 and 14) are performed This way, if you have to restore a backup, your backup will be of the latest, index rebuilt version
Summary
Index fragmentation is an issue all databases experience and, if it is not removed on a regular basis, it can lead to query performance problems One way to remove index fragmentation
is to regularly run the Rebuild Index task, which drops and rebuilds every index in a database While the Rebuild Index task is very effective at what it does, it is considered an offline activity, and it is very resource intensive As such, using this task may not always be appropriate for all your databases In the next chapter, we take a look at an alternative to the Rebuild Index task, that is, the Reorganize Index task
Trang 5In some situations, the Reorganize Index task, coupled with the Update Statistics task (covered in the next chapter), provides a useful alternative to the Rebuild Index task But before I go any further, let me state again, very clearly, that you should not run the Reorganize Index task if you are running the Rebuild Index task These tasks perform essentially the same function, and there is no point in repeating the same step Unfortunately, the Maintenance Plan Wizard is not smart enough to prevent you from making this mistake, and will let you create and schedule both of them
Since Reorganize Index works to achieve essentially the same goal as the Rebuild Index task, namely maintaining the health of your database indexes, many of the arguments regarding when to use the task, how often, and so on, are exactly the same as those discussed
in the previous chapter Therefore, I will not repeat them here
An Overview of the Reorganize Index Task
Like the Rebuild Index task, the Reorganize Index task works to minimize wasted space and logical fragmentation in database indexes It can be regarded in some ways as a lightweight alternative to the Rebuild Index task As the name suggests, Rebuild Index drops the index and rebuilds it from scratch Reorganize Index is more of a gentle
reshuffling of the leaf-level pages of an index, such that the physical ordering matches the logical ordering, and wasted space is minimized
Because Reorganize Index is an online operation, queries can still access the indexes even while they are being reorganized, though some deterioration in performance may be noticed
In addition, this task does not automatically update statistics like the Rebuild Index task does, so this action must be performed separately, using the Update Statistics task Using its default settings, the Reorganize Index task runs the following T-SQL statement for every table in the selected databases