|
|
|
SSC Eights!
      
Group: General Forum Members
Last Login: Monday, May 13, 2013 2:42 PM
Points: 877,
Visits: 1,158
|
|
Really nice article, very well written. Thanks.
Thanks
|
|
|
|
|
SSCoach
         
Group: General Forum Members
Last Login: 2 days ago @ 1:46 PM
Points: 18,732,
Visits: 12,329
|
|
|
|
|
|
Grasshopper
      
Group: General Forum Members
Last Login: Wednesday, February 20, 2013 8:01 AM
Points: 21,
Visits: 275
|
|
Thanks for the fine article. It raises a few questions for me.
- How is the optimizer affected by FF? - If a FF of 50 is used, causing twice as many reads as a FF of 100, then could it cause the optimizer to not use an index? - If, in this same scenario, the leaves eventually get more filled will the optimizer start using the index because less reads are required? - Since I operate in a 24/7 environment, I have to try to minimize the amount of index rebuilding I do, since it locks the table for the duration of the rebuild and causes blocking for my users. I have a few fairly large tables (~10,000,000 rows, ~600,000 pages) that are heavily used for both reads/selects and DML. To minimize index rebuilding, would it make sense to go with a lower fill factor, knowing that would penalize the selects? In other words, does a lower fill factor keep an index from getting fragmented as quickly?
|
|
|
|
|
SSC Journeyman
      
Group: General Forum Members
Last Login: Thursday, April 25, 2013 10:59 AM
Points: 76,
Visits: 95
|
|
Thanks for the great article.
We do index rebuilds every two weeks, and Fill Factor plays an important role.
I have found that the "magic number" for FF would be the amount of index space that needs to be available between index rebuilds. Our indexes grow approximately 4% per week (8% every two weeks), so I have a FF of 90%.
Theoretically, that keeps the system with 2% to 10% of free space in the index pages at any given time. From a general performance standpoint, you never want 100% page usage in a database that is written to. (This would be optimal in a read-only scenario.)
This is just the tip of the iceberg on a huge topic, and proper index maintenance can sometimes make or break the performance of a set of data.
Well, that's my two cents!
Happy Holidays!
-John
|
|
|
|
|
Ten Centuries
      
Group: General Forum Members
Last Login: Monday, May 13, 2013 4:17 AM
Points: 1,123,
Visits: 4,422
|
|
|
|
|
|
Say Hey Kid
      
Group: General Forum Members
Last Login: Monday, May 13, 2013 9:25 AM
Points: 670,
Visits: 2,026
|
|
JottoMagic (12/17/2010)
I have found that the "magic number" for FF would be the amount of index space that needs to be available between index rebuilds. Our indexes grow approximately 4% per week (8% every two weeks), so I have a FF of 90%.
+1 for the general methodology: I've seen automatic index maintenance jobs which have the SQL Agent Job Step Advanced "write output to log file" enabled, and they record the scan density, logical fragmentation percentage, index size in pages before the reorg/rebuild, and current fillfactor of every index they cover.
Every once in awhile, the logs are reviewed, and indexes that are reorganized or rebuilt "too often" get a lower fillfactor. Watching the results, the lower fillfactor index size is (almost) always smaller than the size the index grew to between reorg/rebuild runs.
|
|
|
|