Contraintes liées au disque dur

des variations électromagnétiques de la surface par les têtes, mais la vitesse de rotation du disque constitue également une limite à la lecture des données.

Si une page dont SQL Server a besoin ne se trouve pas sous la tête de lecture/écriture, le contrôleur du disque doit attendre que la section contenant la page tourne pour se positionner sous la tête en question. Par conséquent, la vitesse de rotation du disque conditionne la rapidité avec laquelle les données sont présentées à la tête de lecture/écriture et la vitesse de lecture et d’écriture des bits par la tête. Les limitations de rotation de disque sont donc importantes pour l’ordre et la longueur des requêtes de données. Le moteur de stockage de SQL Server traite les lectures et écritures autant que possible par lots et ordonne les pages conformément à leur ordre sur le disque. L’objectif est de lire les données le plus possible dans l’ordre de numérotation des pages afin de réduire au minimum l’attente liée au positionnement de la section appropriée sous les têtes. Les compteurs Moy. disque, octets/transfert (Avg Disk Bytes/Transfer), Moy. disque, octets/lecture (Avg Disk Bytes/ Read) et Moy. disque, octets/ écriture (Avg Disk Bytes/Write) de l’Analyseur de performances vous indiquent combien d’octets sont demandés à chaque opération d’E/S. Les lecteurs dédiés aux bases de données SQL Server n’auront jamais moins de 8196 octets par transfert, mais votre souhait est d’avoir une valeur homogène de 65 536 octets par transfert (ou plus) (65 536 octets ou 64 K correspondent à une extension).

Si la valeur moyenne est inférieure à celle-ci, vous avez probablement un problème de fragmentation. L’Analyseur de performances affichait une utilisation excessive du disque, mais j’avais besoin d’un autre outil pour identifier la cause du phénomène. FileMon est un outil gratuit de Sysinternals (http://www.sysinternals. com) qui signale toutes les lectures et écritures, ainsi que le nombre d’octets par opération pour l’ensemble des fichiers. Lorsque vous définissez un filtre FileMon afin de surveiller uniquement les fichiers de base de données, vous pouvez voir aisément la quantité d’octets lue et écrite par SQL Server pour chaque fichier d’un groupe de fichiers. Lorsque j’ai constaté que FileMon indiquait uniquement 8196 octets par lecture pour un fichier comportant une table de 2,5 Go et environ 1 Go d’index, j’ai su que j’avais vraisemblablement identifié le coupable à l’origine de mes problèmes de performances. Si l’on considère que chaque E/S inclut un certain retard lié au contrôleur attendant que le disque se positionne sous la tête de lecture/écriture, il est donc toujours plus long de lire huit pages que de lire une extension. Par ailleurs, le moteur de stockage ne peut pas ordonner les lectures pour un accès efficace car il ne sait pas prédire les requêtes qui vont être soumises.

L’optimisation du disque consiste à combiner deux aspects : le stockage des données en segments importants de données et des accès disque réduits au strict minimum. Le rapport de FileMon selon lequel le moteur de stockage lisait une table de 2.5 Go page par page signifiait que quelque chose empêchait le moteur de regrouper les requêtes en extensions. Il était temps d’examiner quelques tables pour en trouver la cause.