Blog Post

The FILL FACTOR impact on the indexes fragmentation

,

This is a short post that is considering the indexes fill factor impact on the fragmentation. Analysis of indexes is a continuous process on the company’s databases that you, as a DBA, must follow and monitor well. This post shows how changing the fill factor impacts the fragmentation. I’m going to show how it is with big indexes. By “big” here, the indexes range is the sizes range from 10GB to 50GB. Next table lists some of the biggest indexes in a client database.

schema table_name index_name FF(%) new FF (%)
ipc TPrimaryTransaction IPT_AmountAM 100 97
ipc TPrimaryTransaction IPT_ExpID 100 95
ipc TPrimaryTransaction IPT_PACVATOIDAmAmAmDc 100 95
ipc TPrimaryTransaction IPT_PrimaryAccount_OID 100 97
ipc TValueTransaction IVT_TAN 100 98
ipc TPrimaryAccount IPA_IACCONAACPACOIDDefTA 100 98

The indexes fill factor was the default (0) or 100%. The fill factor was changed to a different values.

Indexes with default FILLFACTOR (not changed)

The specific matter here is that the change is tiny, i.e. the fill factor is lowered just a few percentages ranging from 2 – 5%. The reason for it is the size of the indexes compared to the amount of fresh data that enters the table (the indexes) on a daily basis. A tiny volume of data is being inserted during the day, but because it’s an OLAP-like system the majority of new data comes during an over-night loading.

IPCBanker Before 241,000 inserts After 241,000 inserts
Index name Fragm. Pages Fragm. Pages
IPT_AccountFolio_OID 0.07 995393 0.07 997625
IPT_AmountAM 0.15 1038548 3.4 1059734
IPT_AmountDB 0.1 662940 0.32 664427
IPT_ExpID 0.35 1452168 0.53 1457063
IPT_IACOIDAmAmVATOID 0.21 1905967 12.93 2071323
IPT_IACOIDVATOIDAMDAMA 0.05 2083536 0.81 2094138
IPT_InternalAccount_OID 0.41 995405 1.6 1003186
IPT_PACVATOIDAmAmAmDc 0.2 2083538 6.34 2168492
IPT_PrimaryAccount_OID 0.22 995404 10.75 1069195
IPT_TransactionComponent_OID 0.05 871307 0.41 873880
IPT_ValueTransaction_OID 0.24 871303 0.24 873256
IPT_VAT_IAC 0.29 1369185 0.43 1373697
IPT_VATTRCOID 0.22 1247028 0.32 1250875
IPT_VoucherLine_OID 0.08 995406 0.08 997640
PK__TPrimary__51B1E56F0D84EF7E 0.01 8363975 0.01 8384221

This is the indexes fragmentation after a rebuild algorithm was run on the database.

Figure 1. Fragmentation of the indexes with default fill factor

The maximum fragmentation reached 12% (Figure 1). This is high after one run of the Daily Interface (DI) tool. Some other indexes also got high fragmentation.

Indexes FILLFACTOR changed

I’m repeating the same process, but now with changed fill factor for the indexes. I additionally repeated the test with more inserts. However, the inserts vary on a daily basis ranging from 200K to 400K inserts per a load.

IPCBanker Before 241,000 inserts After 241,000 inserts
Index name Fragmentation Pages Fragmentation Pages
IPT_AccountFolio_OID 0.07 997625 0.08 999749
IPT_AmountAM 0.01 1067312 0.55 1071701
IPT_AmountDB 0.32 664427 0.53 665841
IPT_ExpID 0.53 1457063 0.74 1462123
IPT_IACOIDAmAmVATOID 0.01 2001201 0.66 2009439
IPT_IACOIDVATOIDAMDAMA 0.81 2094138 1.11 2099646
IPT_InternalAccount_OID 1.6 1003186 1.94 1006148
IPT_PACVATOIDAmAmAmDc 0.22 2127859 2.09 2153097
IPT_PrimaryAccount_OID 0.05 1047361 0.56 1050825
IPT_TransactionComponent_OID 0.41 873880 0.63 875810
IPT_ValueTransaction_OID 0.24 873256 0.24 875115
IPT_VAT_IAC 0.43 1373697 0.58 1378635
IPT_VATTRCOID 0.32 1250875 0.47 1254919
IPT_VoucherLine_OID 0.08 997640 0.08 999763
PK__TPrimary__51B1E56F0D84EF7E 0.01 8384221 0.01 8403603

Figure 2. Fragmentation of the indexes with changed fill factor

The maximum fragmentation reached 2%, which is different from the 12% in the previous test.

Discussion

The fill factor for the indexes has the default value of 0 or 100, which means fulfilment of the index (usually B-trees) of 100%. It can be changed for all newly created indexes in the sys.sp_configure on instance level as Database property using the following command:

EXEC sys.sp_configure N'fill factor (%)',N'95'
GO
RECONFIGURE WITH OVERRIDE
GO

If you want to change the fill factor for an index, then you can do it only for that index. You can simply rebuild the index with a different fill factor option.

Having lower fill factor causes the number of the page splits are less, but at the same time it makes the memory buffer has more pages. Setting the fill factor is a matter of continuous checking your indexes so that you’re nearing the optimum after a period of monitoring it. An index fragmentation is said to be good if it is below 5 – 10%. For heavy indexes it’s better to keep it lower, and for smaller indexes it’s not a problem to be even higher. However, it’s most important that the fragmentation of indexes is stable.

Final words

  • You have to maintain your indexes so that they have low fragmentation. Low fragmentation has itself many benefits. It makes queries faster and keeps some wait types low like for example CXPACKET.

  • Indexes which are overloaded with bulked portions of the data is better to have lowered fill factor. There is not a formula what the lowering should be. On different systems I’ve been using lowering from 0 to 30% and it very depends on the size of the index and the nature of the data that is inserted. A good practice is to start with a lowered fill factor and then follow the index fragmentation so until its fragmentation becomes stable.

Original post (opens in new tab)
View comments in original post (opens in new tab)

Rate

You rated this post out of 5. Change rating

Share

Share

Rate

You rated this post out of 5. Change rating