Performance Tuning with SQL Server Dynamic Management Views

Chapter 5: Indexing Strategy and Maintenance
the index. These standards should be taken lightly, as a more heavily trafficked index may
need to be rebuilt at a lower fragmentation level, and a less active index could conceivably
wait until its fragmentation reaches the rebuild range, and so is never reorganized.
I tend to stick with these standards, except in extreme cases. If we go by those standards,
it is a decent assessment to state that our demo database is in decent shape from an index
fragmentation angle. I would recommend running reorganization commands against the
clustered and non-clustered indexes with less than 30% fragmentation, and rebuilding the
two clustered indexes with fragmentation in excess of 30%.
For the fragmented heap (demo.sch1.DB340534), I would identify a clustering key and
create the clustered index. If, for some reason, a heap is warranted, then I'd still identify a
clustering key, create the clustered index, and then drop the index. The data will remain
ordered based upon the clustering key identified, but will revert back to a heap object
once you drop the clustered index. Alternatively, if I'm lucky enough to be using a SQL
Server 2008 instance, I can issue ALTER TABLE…REBUILD.
Now that we've shown you how to identify fragmentation in your indexes and heaps,
how do you go about resolving it, without manually crafting a reorganization or rebuild
command for each index identified as being fragmented beyond acceptable levels? I've
created many iterations of such a script over the years, but I've scrapped it in favor of one
created by Andrew Kelly, published in the July 2008 issue of SQL Server Magazine
(www.sqlmag.com/Article/ArticleID/99019/Rebuild_Only_the_Indexes_that_
Need_Help.html). Based on his code, I generated a SQL Agent job that I schedule and
run against selected databases, and rebuild/reorganize indexes accordingly.
214