Discussion :

[Donpi]

Bonjour,

est il possible d'avoir un FILL_FACTOR variable ? dans un même index ?

Je m'explique:

J'ai des données qui arrivent tout au long de la journée. Elle sont indexé sur la date + deux ou trois autres données.
Au cour de la journées les données arrivent dans le désordre, donc il me faut un petit FILL_FACTOR.

En revanche, à partir du lendemain les données sont dans le bon ordre et le FILL_FACTOR peut être à 100.

Y-a-t il une solution ?

Merci

[Rei Ichido]

Je vous cite la page MS sur le sujet :

An explicit FILLFACTOR setting applies only when the index is first created or rebuilt. The Database Engine does not dynamically keep the specified percentage of empty space in the pages. For more information, see CREATE INDEX (Transact-SQL).

To view the fill factor setting, use sys.indexes.

En d'autre termes, à moins que vous ne fassiez du rebuild index, changer le fillfactor ne sert à rien.

EDIT : et si vous faites du rebuild, rien ne vous empêche de spécifier à ce moment là quel fillfactor vous voulez utiliser.

[Donpi]

Je veux bien faire un rebuild de mes indexes pour remplis l'espace inutilisé, mais j'ai constamment besoin d'un FILL_FACTOR bas pour les nouvelle données...

Concrètement je n'aimerais pas que ma table garde 50% d'espace vide dans des pages qui ne seront plus modifié si je met un FILL_FACTOR de 50.

[elsuket]

Bonjour,

C'est compréhensible. Certes le FILLFACTOR n'est utilisé qu'à la reconstruction d'un index, et il est évident qu'ensuite SQL Server remplit les pages de l'index autant que cela lui est possible.

Pour adresser votre problème, vous pouvez avoir recours :

- Si vous utilisez une édition Enterprise, au partitionnement de table. Dans votre cas, vous partitionnez suivant la date. On peut alors reconstruire un index sur une partition spécifique (attention cela se fait hors-ligne uniquement)

- Si vous utilisez une autre édition ou que vous ne pouvez pas vous permettre de faire de la reconstruction d'index hors-ligne, alors il faudra opter pour une vue fédérée : vous aurez donc une table par jour. Il vous faut pour cela mettre une contrainte CHECK sur la colonne date de chacune des tables, de façon à ce que l'optimiseur de requête et le moteur de stockage n'aient pas besoin de parcourir toutes les tables pour savoir dans laquelle il faut lire ou écrire des données. Vous construisez ensuite dynamiquement par un job la nouvelle table et redéfinissez la vue qui est l'UNION ALL de toutes ces tables. Vous pouvez alors réaliser les lectures et écritures en spécifiant la vue. Dans ce cas, toutes les tables, excepté celles de la journée courante, ont un FILLFACTOR à 100. La table de la journée courante à un FILLFACTOR plus faible. L'avantage ici est que vous avez des statistiques de colonne et d'index au niveau journée, ce qui est plus fin, et peut procurer de meilleures performances.

- Une solution alternative : vous avez une table partitionnée pour les lignes "d'archive", et une table en plus dans laquelle vous réalisez les écritures de la journée. Une vue vient là-dessus faire l'UNION ALL entre la table partitionnée et la table de la journée. Vous pouvez alors gérer le FILLFACTOR comme bon vous semble. Quand vous avez besoin d'archiver, vous réalisez une fusion de l'ex table du jour avec un ALTER TABLE ... SWITCH TO, après avoir créé la nouvelle table du jour.

@++

[Donpi]

- Une solution alternative : vous avez une table partitionnée pour les lignes "d'archive", et une table en plus dans laquelle vous réalisez les écritures de la journée. Une vue vient là-dessus faire l'UNION ALL entre la table partitionnée et la table de la journée. Vous pouvez alors gérer le FILLFACTOR comme bon vous semble. Quand vous avez besoin d'archiver, vous réalisez une fusion de l'ex table du jour avec un ALTER TABLE ... SWITCH TO, après avoir créé la nouvelle table du jour.

Malheureusement j'ai une Standard 2012 et forcément besoin qu'elle soit UP 99% du temps ( Relation avec d'autres pays etc... ).

J'ai de toute façon opter pour une solution proche de celle citée.
Ou j'ai une table d'historique (archive ça fait peur par ici) et une table qui contient les 16 dernières semaines de données.

Dans la table d'historique j'ai déjà un FILL_FACTOR à 100, mais c'est bien pour la petite table qui contient tout de même 1.8 mio lignes que je veux faire un peu de tuning car au feeling il me faudrait un FF entre 50 et 70.

Notez que si il n'y a pas de solution je pourrais vivre avec.

[SQLpro]

en pratique il est totalement déraisonnable de descendre en dessous de 75% de FF. En effet, déjà avec ce facteur votre index va grossir de l'ordre de 30% lors de la création. A 50 il double de volume.
Personnellement je travaille avec des bases qui atteignent le milliard de ligne, et dans ces volumes là je ne descend jamais en dessous de 90%

A +