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…