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 ««12

The FILL FACTOR Expand / Collapse
Author
Message
Posted Thursday, December 16, 2010 9:42 PM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Today @ 8:09 AM
Points: 1,041, Visits: 1,314
Really nice article, very well written. Thanks.

Thanks
Post #1036309
Posted Friday, December 17, 2010 12:03 AM


SSC-Insane

SSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-Insane

Group: General Forum Members
Last Login: Today @ 10:11 AM
Points: 21,346, Visits: 15,022
Thanks for the article.



Jason AKA CirqueDeSQLeil
I have given a name to my pain...
MCM SQL Server


SQL RNNR

Posting Performance Based Questions - Gail Shaw
Posting Data Etiquette - Jeff Moden
Hidden RBAR - Jeff Moden
VLFs and the Tran Log - Kimberly Tripp
Post #1036352
Posted Friday, December 17, 2010 9:57 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: 2 days ago @ 8:01 AM
Points: 23, Visits: 310
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?
Post #1036627
Posted Friday, December 17, 2010 10:12 AM


SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Wednesday, June 4, 2014 1:20 PM
Points: 80, Visits: 116
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
Post #1036636
Posted Sunday, December 19, 2010 11:58 PM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Thursday, July 24, 2014 7:10 AM
Points: 1,155, Visits: 4,624
Thanks brian.
nice article...easily understandable!


Muthukkumaran Kaliyamoorthy

Helping SQL DBAs and Developers >>>SqlserverBlogForum
Post #1037040
Posted Monday, December 20, 2010 7:42 AM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: 2 days ago @ 8:10 AM
Points: 861, Visits: 2,360
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.
Post #1037196
« Prev Topic | Next Topic »

Add to briefcase ««12

Permissions Expand / Collapse