Beginning Microsoft SQL Server 2008 ... - S3 Tech Training

Chapter 9: SQL Server Storage and Index Structures
Now, the question is how do we use this information once we have it? The answer is, of course, that it
depends.
Using the output from our fragmentation query, we have a decent idea of whether our database is full,
fragmented, or somewhere in between (the latter is, most likely, what we want to see). If we’re running
an OLAP system, then having full pages would be great — fragmentation would bring on depression.
For an OLTP system, we would want much the opposite (although only to a point).
So, how do we take care of the problem? To answer that, we need to look into the concept of index
rebuilding and fillfactors.
ALTER INDEX and FILLFACTOR
294
Stat What It Means
Logical Scan
Fragmentation
Extent Scan
Fragmentation
The percentage of pages that are out of order as checked by scanning the leaf
pages of an index. Only relevant to scans related to a clustered table. An out-oforder
page is one for which the next page indicated in the index allocation map
(IAM) is different from that pointed to by the next page pointer in the leaf page.
This one is telling whether an extent is not physically located next to the extent
that it should be logically located next to. This just means that the leaf pages of
your index are not physically in order (though they still can be logically), and
it shows what percentage of the extents this problem pertains to.
As we saw earlier in the chapter, SQL Server gives us an option for controlling just how full our leaf
level pages are and, if we choose, another option to deal with non-leaf level pages. Unfortunately, these
are proactive options. They are applied once, and then you need to reapply them as necessary by
rebuilding or reorganizing your indexes to reapply the options.
To rebuild indexes, we can either drop them and create them again (if you do, using the DROP_EXISTING
option usually is a good idea), or make use of the ALTER INDEX command with the REBUILD option.
Keep in mind, however, what was said previously about rebuilding indexes — unless you have the
ONLINE option available, rebuilding indexes takes the index (and possibly the entire table) totally offline
until the rebuild is complete. In general, reorganizing is going to be a better option.
A reorg affects only the leaf level of the index (where most of the issue is likely to be anyway) and keeps
the index online while the reorg is taking place. Reorganizing your indexes restructures all the leaf level
information in those indexes, and reestablishes a base percentage that your pages are full. If the index in
question is a clustered index, then the physical data is also reorganized. Unfortunately, REORGANIZE
does not allow for the change of several index settings, such as FILLFACTOR.
If the index has not had a specific fillfactor specified, the pages will be reconstituted to be full, minus
two records. Just as with the CREATE TABLE syntax, you can set the FILLFACTOR to be any value between
1 and 100 as long as you are doing a full rebuild (as opposed to just a reorg). This number will be the
percent that your pages are full once the database reorganization is complete. Remember, though, that as
your pages split, your data will still be distributed 50-50 between the two pages — you cannot control
the fill percentage on an ongoing basis other than by regularly rebuilding the indexes.