Seems I was quoted in another SSWUG email daily newsletter a while back. The topic of conversation for quite a few days was index fragmentation and how to handle it.
The link above may not work well for everyone as I can’t find a way to get a bookmark to take you directly to the quotation, but below is the original topic and my response quoted in the newsletter on 07/07/2010.
Index Defragmentation – How Often Do You See the Need?
Once again, on the list servers here on SSWUG there is a solid discussion about index defragmentation and an application that sets up maintenance plans.
First, a question – please take just a minute and let me know – how often (on average, yes I realize it is variable) do you find yourself needing to defragment your indexes on your production databases?
…and here’s Patrick’s experience – “We have a variety of systems that we support (120 servers/150 instances (2000/2005/2008)) and my experience shows that for many systems we are able to simply ignore the fragmentation levels because the performance of the system is not negatively impacted enough by the fragmentation to become a squeaky wheel. That said, however, some of our largest systems (0.5TB to 0.8TB in size with tables approaching 120GB) require outages and defragmentation every 6 months to keep performance at an acceptable level. We have a custom built SProc that we run on a weekly basis on the majority of the systems that sends us an email based report on the fragmentation levels of the indexes and also has internal logic to identify what actions should be taken based on best practices (defrag/rebuild/drop & recreate). This rarely gives us any grief and I feel we’ve effectively addressed fragmentation from a performance standpoint enterprise wide.
Yes, you will likely find some heavily fragmented tables/indexes here and there, but by and large we have very few performance complaints that can be tracked down specifically to fragmentation (I feel due to the process we have and use). 9 times out of 10 it’s an I/O bottleneck or someone running a report where it shouldn’t be run.”