Valeur correcte pour le facteur de remplissage pour les index cluster avec des clés d'identité de substitution

J'ai une grande table qui a un index groupé avec une clé primaire d'identité. Je décide de la valeur correcte du facteur de remplissage pour ce tableau afin de minimiser les fractionnements de page. Nous maintenons des index à l'aide d'un script exécuté quotidiennement qui mesure la fragmentation et prend les mesures appropriées. Le tableau contient des colonnes de longueur variable.

Ma première pensée a été de le fixer à 100 (car les enregistrements ne doivent être écrits qu'à la fin du tableau), mais je suppose que les modifications apportées aux colonnes de longueur variable peuvent également provoquer des sauts de page, donc je vire maintenant vers 90.

Tout conseil apprécié.

Ça dépend

C'est un acte d'équilibre. Si votre table est intensive en lecture, avec peu de mises à jour ou de suppressions, la valeur par défaut (qui est 100) devrait être correcte.

Si votre table est très gourmande en écriture, avec beaucoup de mises à jour, une valeur inférieure à 80 peut être plus appropriée.

Il n'y a pas de formule magique pour ce genre de choses. (AFAIK, s'il y en a s'il vous plaît faites le moi savoir) La meilleure chose à faire est d'avoir un environnement de test, d'avoir une charge de travail à tester. Apportez les modifications et voyez comment votre base de données fonctionne avec la charge de travail.

Nick a à peu près raison.

Si vous effectuez des mises à jour qui augmentent la taille d'un enregistrement sur des pages compressées, vous provoquerez des fractionnements de page, mais à part cela, avec une clé primaire d'identité, rien ne provoquera de fractionnement de page dans l'index cluster.

(Bien que cela soit dit, le moteur de stockage peut effectuer 5 types de fractionnements de page, et ils ne provoquent pas tous la fragmentation et le mouvement des données - celui que vous obtenez lors de l'insertion de valeurs d'identité augmentant de façon monatonique est un fractionnement de fin de page. Mais Je digresse...)

J'ai aidé de nombreux clients avec cela et j'ai écrit le BOL autour de tout cela - si vous voulez simplement choisir une valeur comme enjeu sur le terrain, 70% ont connu le plus de succès. Comme le dit Nick, surveillez et modifiez le cas échéant.

Choisir un fillfactor pour n'importe quel index est un acte d'équilibrage de la quantité d'activité qui pousse la plénitude de la page vers 100% et de la fréquence à laquelle vous pouvez prendre des mesures correctives pour réinitialiser le fillfactor. Vous devez penser à combien d'espace sera initialement `` gaspillé '' sur les pages si vous définissez le facteur de remplissage vraiment bas, comme 50%, mais encore une fois, j'ai vu que cela était approprié dans certains cas.

Vous devez également considérer comment l'index sera utilisé. Si c'est uniquement pour les recherches singleton, vous pourriez vous en sortir avec un facteur de remplissage inférieur et plus de temps entre la reconstruction / la défragmentation car vous n'allez pas perdre trop d'ES / mémoire d'avoir une grande partie de l'index clusterisé peu peuplé en mémoire. Pour effectuer des numérisations à grande échelle, vous voudriez avoir le facteur de remplissage un peu plus élevé, pour augmenter les E / S et l'efficacité de la mémoire.

Il y a aussi la question OLTP vs DW - généralement un DW est immuable, donc les index auraient 100% de facteur de remplissage. OLTP est la partie difficile.

Après avoir trié l'index clusterisé, n'oubliez pas que les non-clusters auront également besoin d'attention car ils seront très probablement fragmentés.

Lors de la réinitialisation du fillfactor, n'oubliez pas que vous avez le choix entre la reconstruction et la défragmentation. DBCC INDEXDEFRAG / ALTER INDEX ... REORGANIZE peut réinitialiser le fillfactor dans certains cas pour les index qui ne sont pas très fragmentés.

J'espère que cela t'aides!

(Désolé pour la 'réponse excessive' - l'un de mes raccourcis, après avoir écrit le code :-)