July 26, 2013 at 9:00 am
First - a little background - I'm a new DBA for my company and am trying to wrap my head around index fragmentation and some practices I've been reading about. This all started with about 30 location specific databases that are all queried overnight to gather information for reporting. Occasionally a couple of the db's show locks being caused by our script so I started looking at possible fixes. Though index fragmentation may not be the actual cause, it's something I've been looking through.
As I've been reading I've read information ranging from "re-index often" to "you don't need to worry about re-indexing." I've read that indexes fragmented < 30 % should be reorganized and >30 % completely rebuilt. I've read that reorganize can be done online and that rebuild could be either offline or online. I've also come across Ola Hallengren's site (http://ola.hallengren.com/) that has a good script to analyze and decide whether to reorganize/rebuild an index automatically and the script will perform the appropriate action.
At this point, I'm only focused on the index fragmentation of 1 table and each index (with 1 exception) has fragmentation around 98%. The size and read/write frequency is database specific due to some locations are busier than others.
What I'm asking you guys is what other resources am I missing? Are my thoughts completely off? What other scripts/articles would you guys suggest going through to analyze my indexes and fragmentation?
Thank you all very much for taking the time to read through this, I appreciate it very much. My apologies if I haven't provided enough information in this post.
July 31, 2013 at 3:03 pm
August 1, 2013 at 9:31 am
If the issue is limited to one single table I'd check it's clustered key choice. Fragmentation is most often the results of page splits which are most often caused by sub-optimal clustered index key choice. If you manage to use a better key as clustered index, this might solve your fragmentation issue.
Also check fillfactor of the index. This will not avoid fragmentation but postpone it because a page can handle more inserts before a page split occurs
If fragmentation can be avoided, index rebuilds will also be postponed. Which is a good thing as well for your application as for your maintenance window.
August 1, 2013 at 11:04 am
Geert Vanhove (8/1/2013)
If the issue is limited to one single table I'd check it's clustered key choice. Fragmentation is most often the results of page splits which are most often caused by sub-optimal clustered index key choice. If you manage to use a better key as clustered index, this might solve your fragmentation issue.Also check fillfactor of the index. This will not avoid fragmentation but postpone it because a page can handle more inserts before a page split occurs
If fragmentation can be avoided, index rebuilds will also be postponed. Which is a good thing as well for your application as for your maintenance window.
+1
August 1, 2013 at 11:36 am
If you want to analyze your indexes, have a look at sp_blitzindex[/url].
It will tell you what is going on in your database, superb tool that has helped me a lot.
Thanks raadee for the link to sp_blitzindex, will definitely be looking into that one.
If the issue is limited to one single table I'd check it's clustered key choice.
After looking at some stored procs we're having issues with it may be a couple other tables, but the # of tables that are really affected are few so I'll be sure to look into the key choice. Thanks for the info.
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply