> Data > Optimisation des bases de données MS SQL Server – Partie 2

Optimisation des bases de données MS SQL Server – Partie 2

Data - Par Frédéric Brouard - Publié le 24 juin 2010
email

Seconde partie : le serveur - ressources physiques, ressources logiquesJe pose souvent la question en ces termes lors des formations que je donne : parmi les différentes formes d’informatique, laquelle nécessite les machines ayant les plus grandes ressources ? La plupart du temps, les étudiants et les stagiaires m’affirment que c’est l’informatique scientifique, gavée des exploits des antiques Cray et de Deep Blue et des monstres utilisés pour les calculs de la météo. D’autres pensent que ce sont les machines de la conquête spatiale… Peu savent que l’on trouve les systèmes les plus étoffés dans l’informatique de gestion. Un système comme SABRE de United Airlines fut longtemps l’un des systèmes de gestion de bases de données les plus énormes qui soit.

Ce besoin de ressources est lié à deux composantes : des calculs, certes souvent peu complexes, mais surtout la volumétrie des données à manipuler. Des quantités de données parfois si gigantesques qu’il convient de répartir la charge sur de multiples machines car pour certaines bases, aucun ordinateur au monde n’a encore la capacité de traiter seul et dans des temps de réponse acceptables les masses des données en jeu.

Finalement un serveur n’est rien d’autre qu’un ordinateur dont on a sciemment atrophié certains éléments afin de les rendre plus performants qu’un PC de bureau. Voyons ce qu’un serveur n’a peu ou prou besoin. Il n’a pas bien besoin d’un écran puisque qu’il se doit d’être scruté par l’intermédiaire d’autres machines. Il n’a pas non plus réellement besoin d’un clavier ni d’une souris pour les mêmes raisons. En revanche, nous pouvons convenir qu’il a besoin de beaucoup de mémoire comme nous l’avons vu au chapitre précédent. Il a besoin de processeurs rapides (notez le pluriel), de disques de grande capacités dotés des temps de réponses les plus courts. Ce sont donc ces trois axes que nous allons étudier dans cet article. Nous verrons cela du côté physique puis du côté logique. Nous en tirerons quelques nouvelles règles propres à établir les préconisations que tout un chacun doit pouvoir spécifier afin de choisir une machine et la configurer au mieux en fonction de son budget.

Optimisation des bases de données MS SQL Server – Partie 2

Plus il y en a et mieux c’est. À tous les niveaux. La mémoire vive de l’ordinateur, c’est-à-dire la RAM (Random Access Memory), mais aussi toutes les antémémoires possibles et imaginables, que l’on nomme « cache ». Cache au niveau processeur, cache au niveau disque. Les caches servent la plupart du temps à stocker des données temporaires des fichiers du disque. Si une même demande intervient alors que l’antémémoire la contient, alors aucune lecture ne sera réalisée directement sur le disque et cela accélère le débit. Mais il est bien évident qu’un tel cache est toujours limité en taille.

Il possède aussi un inconvénient majeur : celui de bousculer le fonctionnement particulier de SQL Server si le cache est en écriture, à moins qu’il n’ait été spécialement conçu pour travailler avec un SGBDR C/S. De la même façon, on trouve des caches côté processeurs. Mais revenons à la mémoire vive. Sur un OS 32 bits, la mémoire directement adressable ne dépasse pas 4 Go. C’està- dire que seuls 4 milliards de blocs de 8 bits1 peuvent être accédés de manière directe en spécifiant un numéro, un peu à la manière du téléphone qui, en France, permet de joindre 699 999 993 abonnés2 et pas un de plus.

En outre l’OS Windows serveur possède une petite particularité : si vous mettez 4 Go de données, il s’en réservera deux pour son usage exclusif et laissera les deux autres aux applications. Cela convient à la plupart des applications de serveurs qui utilisent en principe massivement l’OS. Or ce n’est pas le cas de SQL Server. Pourquoi ? Parce que SQL Server possède son propre OS ! Un OS qui s’occupe de la gestion du stockage des données sur les disques, de la pagination des données et des procédures en mémoire, et enfin de la gestion concurrentielle des traitements. Bref, SQL Server fait plus de 50 % du travail habituel de l’OS, ne laissant effectivement à Windows que les bribes de la gestion réseau. Dès lors, il serait intéressant de donner à SQL Server un peu plus de mémoire que le 50/50 de la répartition habituelle.

Et bien cela est prévu. Un paramétrage spécial de l’OS au démarrage permet de lui indiquer qu’il ne devra prendre qu’un seul giga octet de RAM et réserver le reste aux applications, en l’occurrence à l’usage quasi exclusif de SQL Server (commutateur 3/GB). Mais que se passe-t-il si l’on a besoin de plus de mémoire vive que la fatidique barre des 4 Go ? Il existe deux techniques pour ce faire : la pagination de la mémoire virtuelle en RAM et le 64 bits…

Téléchargez gratuitement cette ressource

Le XDR au service de la Sécurité IT

Le XDR au service de la Sécurité IT

Découvrez comment mettre à profit le Machine Learning et un traitement analytique orienté sécurité pour corréler les événements, tout en automatisant et en accélérant les processus de détection et de réponse.

Data - Par Frédéric Brouard - Publié le 24 juin 2010