volumineuse et la plus utilisée avait besoin d’un index afin de gérer une contrainte de clé étrangère.

Ce problème spécifique n’était pas réellement dû à la fragmentation, mais plutôt aux analyses de la table avec clé étrangère de 2,5 Go au cours des mises à jour de la table avec clé primaire. Les analyses provoquaient tellement d’E/S qu’il était impossible de dire s’il existait d’autres problèmes de disque. L’ajout de l’index a raccourci de manière spectaculaire les délais de mise à jour et diminué les E/S d’environ 80 pour cent pendant les mises à jour. Pour résoudre les deux problèmes restants, j’ai écrit la procédure stockée uspDefragTables, que nous allons examiner en détail un peu plus loin. Le deuxième problème identifié était le fait que la table était un segment de mémoire. Autrement dit, ses données sont stockées dans l’ordre de leur insertion. Cette condition n’était en elle-même pas préjudiciable.

Les pages de la table n’étaient que légèrement fragmentées car elle recevait environ 75 à 80 pour cent de toutes les insertions exécutées sur l’ensemble des tables de la base de données, ce qui avait pour effet de maintenir ensemble les extensions. Toutefois, ayez à l’esprit que les valeurs de fragmentation logique et d’extension dans DBCC SHOWCONTIG ne s’appliquent pas à un segment de mémoire. Par conséquent, un segment de mémoire avec une valeur de fragmentation de 0 pour cent peut malgré tout être mal organisé par rapport à la manière dont une application demande les données. En fait, l’organisation même des données provoquait les effets similaires à une fragmentation sur l’extraction des données. La table la plus volumineuse contient des informations détaillées sur différents sujets pour les utilisateurs de l’application et la structure de segment de mémoire de la table force les données détaillées de plusieurs utilisateurs à partager la même page. Le résultat est que la récupération de toutes les données pour un utilisateur (ce qui peut se produire des dizaines de fois en l’espace de quelques minutes) force SQL Server à parcourir la table et à lire quelques lignes de chacune des dizaines de pages par utilisateur.

Non seulement il en résulte plus d’E/S, mais vous avez pratiquement l’assurance que les extensions contenant ces pages ne seront pas adjacentes. Par ailleurs, comme la table est sujette à des milliers d’insertions par minute, chaque extension conserve vraisemblablement uniquement un petit nombre de lignes pour chaque utilisateur. Le troisième problème, qui rend l’organisation des données encore moins performante, est le fait que DBCC SHOWCONTIG indiquait une densité de page inférieure à 50 pour cent. Cela signifiait que cette table utilisait plus de deux fois le nombre de pages nécessaires pour stocker les données.

Trop de pages à moitié vides et dispersées dans tout le fichier de base de données constituent la condition idéale pour des performances extrêmement médiocres. La procédure stockée uspDefragTables illustrée sur le listing 2 permet de résoudre les problèmes d’organisation des données et de densité de page.