Click here to monitor SSC
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


The FILL FACTOR


The FILL FACTOR

Author
Message
Hardy21
Hardy21
Ten Centuries
Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)

Group: General Forum Members
Points: 1204 Visits: 1399
Really nice article, very well written. Thanks.

Thanks
SQLRNNR
SQLRNNR
SSC-Insane
SSC-Insane (21K reputation)SSC-Insane (21K reputation)SSC-Insane (21K reputation)SSC-Insane (21K reputation)SSC-Insane (21K reputation)SSC-Insane (21K reputation)SSC-Insane (21K reputation)SSC-Insane (21K reputation)

Group: General Forum Members
Points: 21067 Visits: 18258
Thanks for the article.



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


SQL RNNR

Posting Performance Based Questions - Gail Shaw

dld
dld
SSC Rookie
SSC Rookie (30 reputation)SSC Rookie (30 reputation)SSC Rookie (30 reputation)SSC Rookie (30 reputation)SSC Rookie (30 reputation)SSC Rookie (30 reputation)SSC Rookie (30 reputation)SSC Rookie (30 reputation)

Group: General Forum Members
Points: 30 Visits: 415
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?
JottoMagic
JottoMagic
SSC Journeyman
SSC Journeyman (81 reputation)SSC Journeyman (81 reputation)SSC Journeyman (81 reputation)SSC Journeyman (81 reputation)SSC Journeyman (81 reputation)SSC Journeyman (81 reputation)SSC Journeyman (81 reputation)SSC Journeyman (81 reputation)

Group: General Forum Members
Points: 81 Visits: 124
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
muthukkumaran Kaliyamoorthy
muthukkumaran Kaliyamoorthy
Ten Centuries
Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)

Group: General Forum Members
Points: 1225 Visits: 4838
Thanks brian.
nice article...easily understandable!

Muthukkumaran Kaliyamoorthy

Helping SQL DBAs and Developers >>>SqlserverBlogForum

Nadrek
Nadrek
Ten Centuries
Ten Centuries (1K reputation)Ten Centuries (1K reputation)Ten Centuries (1K reputation)Ten Centuries (1K reputation)Ten Centuries (1K reputation)Ten Centuries (1K reputation)Ten Centuries (1K reputation)Ten Centuries (1K reputation)

Group: General Forum Members
Points: 1029 Visits: 2673
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.
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search