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.
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.
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.
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
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.
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%
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
nice blog
ReplyDeleteSQL Server DBA Online Training hyderabad
Thanks @ Sindhu
DeleteThanks @ Sindhu
DeleteThe 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.
ReplyDeleteIf 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.