Les index sont reconstruits pour supprimer la fragmentation. Il y a mille et un articles et articles de blog sur la nature de la fragmentation d'index, mais @BrentOzar a récemment publié une explication particulièrement concise dans Stop Worrying About SQL Server Fragmentation .
Prenons un peu de recul et faisons comme si votre base de données était un annuaire téléphonique organisé par nom, prénom.
À mesure que les gens emménagent dans votre ville, nous devons les ajouter à l'annuaire téléphonique. Idéalement, chaque page a un espace vide, et nous gouvernons cela avec le facteur de remplissage. Lorsque SQL Server reconstruit les index, il utilise le facteur de remplissage pour décider de l'espace libre à laisser sur chaque page. S'il n'y a pas assez d'espace libre, SQL Server doit faire un réarrangement - mais il ne peut pas exactement pousser une toute nouvelle page au milieu de l'annuaire téléphonique. Le livre est déjà relié. Nous devrons coller plus de pages vierges à la fin.
Problème n ° 1 - Fragmentation interne: nous avons une page nouvellement ajoutée avec presque rien. Problème n ° 2 - Fragmentation externe: les pages de l'annuaire téléphonique sont en panne.
L'article récent de Brent offre une perspective mise à jour sur l'une de ses précédentes séries, Index Fragmentation Findings . L'ancien article met en évidence les statistiques d'études beaucoup plus anciennes sur les effets néfastes de la fragmentation, le plus récent plaide pour atténuer un pourcentage important des inconvénients de performances en s'assurant que votre base de données est entièrement mise en cache.
Ram est maintenant si bon marché que c'est probablement la solution la moins chère, la plus simple et la moins risquée pour une base de données fortement fragmentée. Surtout si la nature de la conception de la base de données est telle qu'elle se fragmentera naturellement malgré les efforts de maintenance.
Mark Storey-Smith
la source
