Comments on: Index Fragmentation Findings: Part 2, Size Matters http://www.brentozar.com/archive/2009/02/index-fragmentation-findings-part-2-size-matters/ Your technology pain-relief experts. Wed, 08 Feb 2012 16:37:59 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Brent Ozar http://www.brentozar.com/archive/2009/02/index-fragmentation-findings-part-2-size-matters/comment-page-1/#comment-8861 Brent Ozar Fri, 15 May 2009 15:20:01 +0000 http://www.brentozar.com/?p=2458#comment-8861 Jonathan - everything is "Your mileage may vary." Depends on the random speed of the drives, the read vs write mix of the data, the frequency that the data is queried, etc. My approach is to start with Michelle Ufford's excellent index defrag script, set it with very high thresholds (like only rebuild indexes when things are extremely fragmented) and then see how long it takes to run. Then I turn it down lower and lower over time so that I defrag as much as possible in as little time as possible. Whatever performance gains I can get from it, great, but I don't go to the individual table to look at fragmentation vs size vs read/write mix and so on. Jonathan – everything is “Your mileage may vary.” Depends on the random speed of the drives, the read vs write mix of the data, the frequency that the data is queried, etc. My approach is to start with Michelle Ufford’s excellent index defrag script, set it with very high thresholds (like only rebuild indexes when things are extremely fragmented) and then see how long it takes to run. Then I turn it down lower and lower over time so that I defrag as much as possible in as little time as possible. Whatever performance gains I can get from it, great, but I don’t go to the individual table to look at fragmentation vs size vs read/write mix and so on.

]]> By: JonathanA http://www.brentozar.com/archive/2009/02/index-fragmentation-findings-part-2-size-matters/comment-page-1/#comment-8846 JonathanA Fri, 15 May 2009 11:35:48 +0000 http://www.brentozar.com/?p=2458#comment-8846 Brent, does this scale down at all? I have 3 productions servers. Only one database has indexes that are over 10000 pages, only 3 others have indexes over 1000 pages. I have scheduled jobs that defrag indexes on the main databases (HR, Accounts, CRM etc) as I know they cause slowdowns if they are not kept neat and tidy. Doesnt the frag %age have a vote in whether the index should be rebuilt/reorganised? Or does a 500 page index that is 90% fragged not cause the problems that a 5000 page index that is 2% fragged ... Jonathan Brent, does this scale down at all?

I have 3 productions servers. Only one database has indexes that are over 10000 pages, only 3 others have indexes over 1000 pages.

I have scheduled jobs that defrag indexes on the main databases (HR, Accounts, CRM etc) as I know they cause slowdowns if they are not kept neat and tidy.

Doesnt the frag %age have a vote in whether the index should be rebuilt/reorganised? Or does a 500 page index that is 90% fragged not cause the problems that a 5000 page index that is 2% fragged …

Jonathan

]]> By: Scott R. http://www.brentozar.com/archive/2009/02/index-fragmentation-findings-part-2-size-matters/comment-page-1/#comment-7321 Scott R. Thu, 12 Feb 2009 09:07:09 +0000 http://www.brentozar.com/?p=2458#comment-7321 Brent, Great post and series! Looking forward to part 3. The small / medium / large categories helps put priority and focus where it is needed most - kind of like "don't waste your time" / "look a little closer" / "really pay attention!". While I understand the stated index size thresholds of 10,000 pages and 50,000 pages (and that page count is the metric which was collected), it may also be helpful to offer a relative perspective by stating these thresholds for reference purposes as storage capacity metrics of about 80 MB (10,000 pages x 8 KB page size) and about 400 MB (50,000 pages x 8 KB page size). The "about" caveat depends on whether your preferred storage metric unit measures are decimal (MB = 1,000,000 bytes or 10^6 bytes) or binary (MB = 1,048,576 bytes or 2^20 bytes) - roughly a 5% difference for MB and 7.3% for GB. Scott R. Brent,

Great post and series! Looking forward to part 3.

The small / medium / large categories helps put priority and focus where it is needed most – kind of like "don't waste your time" / "look a little closer" / "really pay attention!".

While I understand the stated index size thresholds of 10,000 pages and 50,000 pages (and that page count is the metric which was collected), it may also be helpful to offer a relative perspective by stating these thresholds for reference purposes as storage capacity metrics of about 80 MB (10,000 pages x 8 KB page size) and about 400 MB (50,000 pages x 8 KB page size). The "about" caveat depends on whether your preferred storage metric unit measures are decimal (MB = 1,000,000 bytes or 10^6 bytes) or binary (MB = 1,048,576 bytes or 2^20 bytes) – roughly a 5% difference for MB and 7.3% for GB.

Scott R.

]]>