2.1 – La vitesse de rotation

l’un contient les données, l’autre le journal. Ces deux fichiers ont une taille minimale et chaque fois qu’il sera nécessaire de l’augmenter pour y stocker des informations, alors une opération de croissance de fichier sera entreprise.

Dans ce cas, si l’on observe ce qui se passe durant la vie de la base, on se trouve confronté à un phénomène qui va diminuer sensiblement les performances d’accès. Ce phénomène, c’est la fragmentation physique. Et il n’est pas possible d’y remédier après coup si la base de données doit être exploitée en continu ! Observons concrètement ce qui se passe dans le cas d’un serveur mono disque pour une base de données que l’on va créer avec les options par défaut.

Voici comment petit à petit, le disque se structure, Voir Figure 1 :
• En rouge figurent les fichiers de l’OS. Ils se trouvent en tête du disque parce qu’ils ont été installés en premier. En bleu figure « l’exécutable » SQL Server : en fait une collection de DLL et de fichier contenant divers programmes s’interfaçant avec les services SQL Server.
• En jaune figure le début de notre fichier journal de la base, et en vert, le fichier des données.
• Enfin, en gris figure un fichier quelconque, par exemple une sauvegarde. On constate qu’au fur et à mesure du remplissage de la base de données, le fichier du journal, comme celui de la base de données se fragmente. Plus la base va vivre et plus la fragmentation sera prononcée. Cette fragmentation impose des lectures du fichier des données qui vont, en terme de temps de réponse, du médiocre à l’exécrable du fait des nombreux sauts que la tête de lecture doit subir pour lire une continuité de données.

Or, MS SQL Server est doté d’un algorithme, qui, lorsque vous demandez, à la création de la base, des fichiers de taille fixe, recherche le meilleur emplacement sur le disque afin de minimiser le trajet des têtes de lecture… Peu de gens le savent, et c’est particulièrement dommage. Autrement dit, lors de la création de la base, vous pouvez déjà optimiser la lecture et l’écriture physique des disques. Il suffit pour cela de créer les fichiers de la base, sur un disque vierge ou préalablement formaté, avec une taille suffisante pour y prévoir 3 à 5 années d’exploitation, c’est-à-dire la durée de vie moyenne d’un serveur…

Si vous faîtes cela, et en particulier sur un disque neuf ou dédié, vous constaterez deux phénomènes :
• le premier est que ce sont les pistes les plus proches du bord externe du disque qui seront utilisées ;
• le second est que si le disque est multi plateaux (et ils le sont presque tous) alors SQL Server choisira ses granules8 sur tous les plateaux. Un jour, créant ainsi une base de données pour un des plus gros sites web d’e-commerce avec cette technique, le DBA, peu au fait de la chose, me montra dans l’outil de d’analyse de fragmentation de Windows combien j’avais tort ! Il voyait que le fichier créé était coupé en quatre parties égales et me lança « vous voyez bien que ça marche pas vot’truc! Le fichier est fragmenté ! » Alors je lui demandais de me fournir les caractéristiques techniques des disques du serveur et faisant le pari que les disques contenaient quatre plateaux.

À la lecture de la documentation, je criais « Bingo ! ». En fait, il faut comprendre que les têtes de lecture des différents plateaux sont solidaires. Si l’une lit au bord, l’autre ne peut lire l’extérieur. En groupant les granules de stockage sur les mêmes cylindres virtuels, SQL Server créé des fichiers qui minimisent le déplacement des têtes. Dès lors le temps d’accès qui est un temps moyen devient beaucoup moins proche de la mesure de ce que l’on obtiendra au final avec une telle stratégie.

 Ainsi, le critère le plus sensible sera donc la vitesse de rotation, car en admettant que la tête ne bouge plus, alors toute la différence se fera entre un disque avec un rpm de 7 200 et un autre de 18 000 (une amélioration de 250 % !). Un internaute a écrit un très bon article sur ce phénomène. Il s’intitule « le disque le plus rapide du monde9» .