Performance Tuning with SQL Server Dynamic Management Views

Chapter 5: Indexing Strategy and Maintenance
I think most of us had our start as DBAs using the SQL Server Maintenance Plans
Wizard built into Enterprise Manager or SQL Server Management Studio. This is how
we cut our teeth when backing up data and log files, checking our databases for errors,
and rebuilding our indexes. The issue with using maintenance plans, particularly for
index maintenance, is that it is an all-or-nothing process: you either rebuild all the
indexes in your database (and all the databases in the maintenance plan) or you rebuild
none of them. There is no middle ground.
Even now, many years and editions later, this rather large hammer is the only built-in tool
at our disposal for performing index maintenance. However, with the help of this DMF,
at least we can find out which indexes really are suffering from fragmentation and then,
based on this, build our own index maintenance plans, which limit rebuilds to just those
indexes that need them, or just clustered or non-clustered indexes, indexes of a certain
size, or of a specific table, and so on. In short, this DMF gives the DBA an element of
control over the index maintenance process that is sadly lacking in the current
Maintenance Plans tool.
A brief overview of index fragmentation
The leaf level of a clustered index is implemented as a doubly-linked list. This means that
every leaf level of the index includes a pointer to both the previous and the next page in
the index. The data will be stored in the logical order dictated by the clustering key and
new data will be added in its correct place on the relevant page. So, assuming there is
room on that page, the logical order will match the physical order.
The pointers in the doubly-linked list make it easy to scan ranges of data and, when the
data is ordered as described above, this becomes a very efficient operation. In turn, nonclustered
indexes on a table with a clustered index, are implemented as a doubly-linked
list, and have the same benefits (by contrast, indexes on heaps are not implemented this
way, and have no knowledge of which page to scan next).
208