1 – Fonctionnement d’un serveur SQL8

marche des transactions.

A cela, il faut ajouter la mémoire vive qui va jouer un rôle essentiel, les disques comptant pour l’instant dans notre histoire pour quantité négligeable9 … Notre singulier utilisateur veut extraire des données et pour cela, lance la commande SELECT… Aussitôt cet ordre SQL – qui, en fait, constitue une transaction – est enregistré par le journal de transaction. Puis, le relais est donné au moteur transactionnel qui scrute la mémoire afin de savoir si les lignes de tables concernées par la requête sont en mémoire.

Si elles le sont, la requête est exécutée en lisant les données en mémoire, l’extraction est produite et le résultat est envoyé au demandeur. Si les données ne figurent pas en mémoire, une demande est envoyée au moteur relationnel d’avoir à les y placer. Tant que cette demande n’est pas entièrement satisfaite, la requête est mise en sommeil. Lorsque le moteur de stockage a effectué son travail, alors le moteur relationnel reprend le sien… Une fois les données délivrées, une marque est effectuée dans le journal pour signaler l’achèvement (bon ou mauvais) de la transaction.

Autrement dit, règle N°1 :
• la lecture des données s’effectue toujours en mémoire. Notre singulier utilisateur veut mettre à jour une donnée… Il utilise pour cela la commande UPDATE. La transaction est enregistrée dans le journal. La donnée est-elle présente en RAM ? Supposons que oui. On modifie directement la donnée en mémoire et on positionne un flag pour indiquer que celle-ci a changé. La transaction opérée est marquée terminée dans le journal. De temps en temps un processus particulier du moteur relationnel scrute la mémoire à la recherche des données modifiées. Il dispose pour cela des flags et va regrouper les écritures pour en optimiser l’enregistrement sur le disque.

On en conclut deux nouvelles règles N°2 et N°3:
• les mises à jour de données s’effectuent d’abord en mémoire (INSERT, UPDATE, DELETE) • l’écriture des données est différée et regroupée Notre utilisateur unique décide de renouveler le SELECT qu’il a entrepris au début de son aventure avec nous. Il est surpris par la rapidité avec laquelle les données lui parviennent cette fois-ci. Pas étonnant les données sont déjà en mémoire. Mieux, la requête est déjà préparée car elle aussi est mise en cache : la façon de la traiter – son plan d’exécution – a déjà été établie. Il n’y a donc plus que le temps de traiter et de renvoyer les données. La mise en cache de la requête consiste tout simplement à répertorier la chaîne de caractère qui symbolise l’exécution de l’ordre SQL, avec la référence de son plan d’exécution.

La règle N° 4 est donc :
• le texte d’une requête est mis en cache avec son plan d’exécution Ces quatre règles édictées, nous pouvons dès à présent constater que l’élément le plus important pour un serveur SQL est la mémoire où sont mises en cache tant les données que les requêtes (et plus généralement les procédures, fonctions, triggers et règles… c’est à dire tous les objets codés en Transact SQL). Il nous faut donc nous intéresser au cache. Comment fonctionne t-il ? Telle est la question, et pour la résoudre nous devons adopter deux points de vue différents : celui des données et celui des procédures, toute en sachant qu’en matière d’alimentation du cache : la règle est commune, c’est LRU qui dicte sa loi… LRU pour Last Recent Use, c’est à dire "moins récemment utilisé". Autrement dit, pour faire place à une nouvelle mise en cache, l’espace mémoire le plus anciennement accédé doit céder sa place.