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

Chapter 9: SQL Server Storage and Index Structures
the different row locations. If you change the structure of the index using DROP_EXISTING, the NCIs are
rebuilt only once instead of twice. Furthermore, you cannot simply drop and re-create an index created by
a constraint, for example, to implement a certain fillfactor. DROP_EXISTING is a workaround to this.
STATISTICS_NORECOMPUTE
By default, SQL Server attempts to automate the process of updating the statistics on your tables and
indexes. By selecting the STATISTICS_NORECOMPUTE option, you are saying that you will take responsibility
for the updating of the statistics. In order to turn this option off, you need to run the UPDATE STATISTICS
command, but not use the NORECOMPUTE option.
I strongly recommend against using this option. Why? Well, the statistics on your index are what the
query optimizer uses to figure out just how helpful your index is going to be for a given query. The statistics
on an index are changing constantly as the data in your table goes up and down in volume and as
the specific values in a column change. When you combine these two facts, you should be able to see that
not updating your statistics means that the query optimizer is going to be running your queries based on
out-of-date information. Leaving the automatic statistics feature on means that the statistics will be updated
regularly (just how often depends on the nature and frequency of your updates to the table). Conversely,
turning automatic statistics off means that you will either be out of date, or you will need to set up a
schedule to manually run the UPDATE STATISTICS command.
SORT_IN_TEMPDB
280
Using this option makes sense only when tempdb is stored on a physically separate drive from the database
that is to contain the new index. This is largely an administrative function, so I’m not going to
linger on this topic for more than a brief overview of what it is and why it only makes sense when tempdb
is on a separate physical device.
When SQL Server builds an index, it has to perform multiple reads to take care of the various index construction
steps:
1. Read through all the data, constructing a leaf row corresponding to each row of actual data. Just
like the actual data and final index, these go into pages for interim storage. These intermediate
pages are not the final index pages, but rather a holding place to temporarily store things every
time the sort buffers fill up.
2. A separate run is made through these intermediate pages to merge them into the final leaf pages
of the index.
3. Non-leaf pages are built as the leaf pages are being populated.
If the SORT_IN_TEMPDB option is not used, then the intermediate pages are written out to the same
physical files that the database is stored in. This means that the reads of the actual data have to compete
with the writes of the build process. The two cause the disk heads to move to different places (read vs.
write). The result is that the disk heads are constantly moving back and forth — this takes time.
If, on the other hand, SORT_IN_TEMPDB is used, then the intermediate pages will be written to tempdb
rather than the database’s own file. If they are on separate physical drives, this means that there is no
competition between the read and write operations of the index build. Keep in mind, however, that this