Saturday, 23 December 2017

What is the best value for the Fill Factor

Introduction
Fill Factor is directly related to Index and Index is directly related to Performance. So for performance point of view Fill Factor play a very important role.
Fill Factor determines the percent of each leaf-level page to be filled with data. By default it is 100 percent. That means all most all the space of 8KB leaf-level page is filled with data.
Here in this article, I am not going to discuss about what fill factor is and how it reduces the index fragmentation. 
If you need the information related to fill factor and how it works, you can search on google. You can find a lot of articles are related to it.
Here in this article I am trying to discuss related to the best value that we can assign to fill factor.
As a SQL developer, we always face this type of scenario. The query in the mind is what the value we choose for fill factor. To resolve this query we just move to DBA and asking them. Sometimes they say 70% or 80%. 
But they don’t provide any explanation for it. Why they have chosen this digit as a value of fill factor and I personally don’t understand how they (DBA) decide them without seeing proper page split. It is really a misty for me. Anyway, they are the Boss and they have full authority to manage Database.

Here in this article I am proving my personal opinion to choosing correct fill factor for index. You can try this or go with the DBA’s definition.
There is no calculative method or mathematical formula to find out the correct fill factor. It’s totally depends on implementation and experience with indexing.
To understand it properly, here I am taking some scenario 

Scenario – 1
I have a table on OLAP environment and there is no DELETE or UPDATE operation is going on. Just new records are inserted.
I suggest that there is no need to implement Fill Factor or go with default Fill Factor 100 Percent.
Sometimes the improper fill factor decreases the performance.
Now let us assume that there is Table 1 which contains the data worth of 1000 pages. All these pages are 100% filled. If I run a query to retrieve all the data from the SQL Server, it should retrieve all the 1000 pages. 
If pages are only 50% failed to accommodate Table 1, it will need 2000 pages, which means SQL Server has to read twice the amount of the data from the disk, leading to higher usage of memory, CPU and IO bandwidth.

Scenario -2
I have a table on OLTP environment and INDERT/UPDATE/DELETE operation is huge.
We can find the Fill Factor of an existing table/Index by

SELECT OBJECT_NAME(OBJECT_ID) Name, type_desc, fill_factor
FROM sys.indexes

First don’t set any fill factor and just create the Index. After one or two week observe the average index fragmentation. 
If the nature table is static and there is no value changed, then there is no need to set any fill factor value.
If the table 
matter is less often Updated table, then set the fill factor value at 95%.
If 
the nature table is frequently Updated table, then set the fill factor value at 70 to 90%

Situation for Fill Factor
Fill Factor %
Static Table – The value of the table never changed
100
Tables Updated Less Often
95
Frequently Updated Table
70 to 90


But all is depends on the ratio of index fragmentation. We must observe the regular index fragmentation ratio and decide the fill factor accordingly. Not to decide any arbitrary digit as a value of fill factor.
We can find the index fragmentation ratio by using this SQL statement

SELECT b.name As [Table Name], c.name As [Index Name], avg_fragmentation_in_percent
FROM   sys.dm_db_index_physical_stats(DB_ID('Practice'), NULL, NULL, NULL , NULL)a
       INNER JOIN sys.tables b WITH (nolock) ON a.OBJECT_ID = b.OBJECT_ID
       INNER JOIN sys.indexes c WITH (nolock) ON a.OBJECT_ID = c.OBJECT_ID
                                                  AND a.index_id = c.index_id
WHERE  b.name = 'ORDER_PRICE'
       AND c.name = 'PK_OrderProduct';


Hope it will be informative.





Posted by: MR. JOYDEEP DAS

4 comments:

  1. The advice of just going with the default Fill Factor of 0/100% in Scenario #1 simply because there are only Inserts being done is highly flawed.

    If the data is inserted out-of-order according to the Key Column(s) of the index, there will be MASSIVE page splits if you rebuild the index at 0/100. You also need to remember that about most of your NON Clustered Indexes will be inserted into in a different order than they will be for the Clustered Index and certainly a Heap.

    Doing index maintenance on 0/100 indexes that have suffered fragmentation will always lead to MASSIVE blocking due to "bad" page splits immediately after such index maintenance.

    To wit, it's actually better to do no index maintenance than it is to do it incorrectly. I'll also state that, even though it's correctly documented, it's poorly worded and seriously leads to people misinterpreting what REORGANIZE does. With that, I'll also state that if your index maintenance includes the use of REORGANIZE as a matter of rote, then you're doing your index maintenance incorrectly.

    ReplyDelete