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

The Database Engine Tuning Advisor is found on the Tools menu of the SQL Server Management Studio.
It can also be reached as a separate program item from the Windows Start menu. Like most any tuning
tool, I don’t recommend using this tool as the sole way to decide what indexes to build, but it can be
quite handy at making some suggestions that you may not have thought of.
Maintaining Your Indexes
As developers, we often tend to forget about our product after it goes out the door. For many kinds of
software, that’s something you can get away with just fine — you ship it, then you move on to the next
product or next release. However, with database-driven projects, it’s virtually impossible to get away
with. You need to take responsibility for the product well beyond the delivery date.
Please don’t take me to mean that you have to go serve a stint in the tech support department — I’m
actually talking about something even more important: maintenance planning.
There are really two issues to be dealt with in terms of the maintenance of indexes:
❑ Page splits
❑ Fragmentation
Both are related to page density, and while the symptoms are substantially different, the troubleshooting
tool is the same, as is the cure.
Fragmentation
Chapter 9: SQL Server Storage and Index Structures
We’ve already talked about page splits quite a bit, but we haven’t really touched on fragmentation. I’m
not talking about the fragmentation that you may have heard of with your O/S files and the defrag tool
you use, because that won’t help with database fragmentation.
Fragmentation happens when your database grows, pages split, and then data is eventually deleted.
While the B-Tree mechanism is really not that bad at keeping things balanced from a growth point of
view, it doesn’t really have a whole lot to offer as you delete data. Eventually, you may get down to a situation
where you have one record on this page, a few records on that page — a situation where many of
your data pages are holding only a small fraction of the amount of data that they could hold.
The first problem with this is probably the first you would think about — wasted space. Remember that
SQL Server allocates an extent of space at a time. If only one page has one record on it, then that extent is
still allocated.
The second problem is the one that is more likely to cause you grief: Records that are spread out all over
the place cause additional overhead in data retrieval. Instead of just loading up one page and grabbing
the 10 rows it requires, SQL Server may have to load 10 separate pages to get that same information. It
isn’t just reading the row that causes effort — SQL Server has to read that page in first. More pages =
more work on reads.
291