Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase

Indexing & Fragmentation Expand / Collapse
Author
Message
Posted Friday, July 26, 2013 9:00 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Thursday, July 24, 2014 1:53 PM
Points: 39, Visits: 145
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.
Post #1478059
Posted Wednesday, July 31, 2013 3:03 PM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Wednesday, August 27, 2014 4:11 AM
Points: 51, Visits: 401
Hi,

you can't miss with Ola's solution regarding maintenance.

If you want to analyze your indexes, have a look at sp_blitzindex.
It will tell you what is going on in your database, superb tool that has helped me a lot.


Post #1479710
Posted Thursday, August 1, 2013 9:31 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Monday, November 18, 2013 6:53 AM
Points: 243, Visits: 101
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.
Post #1479998
Posted Thursday, August 1, 2013 11:04 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Yesterday @ 8:53 PM
Points: 33,204, Visits: 15,353
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







Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #1480042
Posted Thursday, August 1, 2013 11:36 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Thursday, July 24, 2014 1:53 PM
Points: 39, Visits: 145
If you want to analyze your indexes, have a look at sp_blitzindex.
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.
Post #1480052
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse