• Article

Gestion des tampons

L'objectif principal d'une base de données SQL Server est de stocker et de récupérer les données, l'utilisation intensive d'E/S sur disque est donc une caractéristique centrale du moteur de base de données. Étant donné que les opérations d'E/S sur disque peuvent consommer beaucoup de ressources et durent relativement longtemps, SQL Server s'attache à rendre ces opérations efficaces. La gestion des tampons joue un rôle essentiel pour parvenir à cette efficacité. Le composant de gestion des tampons comprend deux mécanismes : le gestionnaire des tampons permet d'accéder et de mettre à jour les pages de base de données, et le cache des tampons (également appelé pool de mémoires tampons), et permet de réduire les opérations d'E/S du fichier de base de données.

Fonctionnement de la gestion des tampons

Un tampon est une page de 8 Ko en mémoire dont la taille est similaire à une page d'index ou de données. Ainsi, le cache de tampons est divisé en pages de 8 Ko. Le gestionnaire des tampons gère les fonctions de lecture des pages d'index ou de données à partir des fichiers de disque de base de données dans le cache de tampons ainsi que la réécriture sur le disque des pages modifiées. Une page reste dans le cache tampon jusqu'à ce que le gestionnaire de tampons ait besoin de la zone de mémoire tampon pour lire davantage de données. Les données ne sont réécrites sur le disque que si elles sont modifiées. Les données dans le cache de tampons peuvent être modifiées plusieurs fois avant leur réécriture sur le disque. Pour plus d'informations, consultez Lecture de pages et Écritures de pages.

Lorsque SQL Server démarre, il calcule la taille de l'espace d'adressage virtuel pour le cache de tampons d'après plusieurs paramètres, dont la quantité de mémoire physique du système, le nombre configuré de threads serveur maximum et divers paramètres de démarrage. SQL Server réserve la quantité ainsi calculée de son espace d'adressage virtuel de processus pour le cache des tampons (appelé la cible de mémoire), mais il acquiert (valide) uniquement la quantité nécessaire de mémoire physique pour la charge actuelle. Vous pouvez interroger les colonnes bpool_commit_target et bpool_committed dans la vue du catalogue sys.dm_os_sys_info pour retourner le nombre de pages réservées au moment de la validation du nombre de pages et de la cible de mémoire dans le cache des tampons, respectivement.

L'intervalle entre le démarrage de SQL Server et le moment où la mémoire tampon obtient sa cible de mémoire s'appelle l'accélération. Au cours de cette opération, les tampons se remplissent de demandes de lecture selon les besoins. Par exemple, une demande de lecture d'une page unique remplit une page de tampon unique. Cela signifie que l'accélération dépend du nombre et du type des demandes clientes. L'accélération s'effectue par la transformation des demandes de lecture de page unique en demandes de huit pages alignées. Cette opération permet au processus d'accélération de s'achever plus rapidement en particulier sur les ordinateurs possédant beaucoup de mémoire.

Comme le gestionnaire de tampons consomme l'essentiel de la mémoire dans les processus SQL Server, il collabore avec le gestionnaire de la mémoire afin de permettre aux autres composants d'utiliser ses tampons. Le gestionnaire de tampons interagit essentiellement avec les composants suivants :

  • Le gestionnaire de ressources pour contrôler l'utilisation de l'ensemble de la mémoire et, sur les plateformes 32 bits, pour contrôler l'utilisation de l'espace d'adressage.

  • Le gestionnaire de base de données et le système d'exploitation SQL Server (SQLOS) pour les opérations d'E/S de fichier peu importantes.

  • Le gestionnaire du journal pour la journalisation préalable.

Fonctionnalités prises en charge

Le gestionnaire de tampons prend en charge les fonctionnalités suivantes :

  • Le gestionnaire de tampons est compatible avec la technologie NUMA (Non-Uniform Memory Access). Les pages de cache des tampons sont réparties sur les nœuds NUMA matériels, ce qui permet à un thread d'accéder à une page de tampons allouée sur le nœud NUMA local au lieu de la mémoire étrangère. Pour plus d'informations, consultez Prise en charge de la technologie NUMA dans SQL Server. Pour comprendre l'affectation des pages de mémoire à partir du cache de tampons lors de l'utilisation de NUMA, consultez Agrandissement et réduction du pool de mémoires tampons sous NUMA.

  • Le gestionnaire de tampons prend en charge l'ajout de mémoire à chaud, ce qui permet aux utilisateurs d'ajouter de la mémoire physique sans redémarrer le serveur. Pour plus d'informations, consultez Ajout de mémoire à chaud.

  • Le gestionnaire de tampons prend en charge l'allocation de mémoire dynamique sur les plateformes Microsoft Windows XP 32 bits et Windows 2003 32 bits lorsque AWE est activé. L'allocation de mémoire dynamique permet au moteur de base de données d'obtenir et de libérer la mémoire efficacement dans le cache de tampons pour prendre en charge la charge de travail en cours. Pour plus d'informations, consultez Gestion dynamique de la mémoire.

  • Le gestionnaire de tampons prend en charge les grandes pages sur les plateformes 64 bits. La taille de la page est spécifique à la version de Windows. Pour plus d'informations, consultez la documentation de Windows.

  • Le gestionnaire de tampons fournit les diagnostics supplémentaires exposés par le biais des affichages de gestion dynamique. Vous pouvez utiliser ces affichages pour contrôler un ensemble de ressources du système d'exploitation spécifiques à SQL Server. Par exemple, vous pouvez utiliser la vue sys.dm_os_buffer_descriptors pour contrôler les pages dans le cache de tampons. Pour plus d'informations, consultez Vues de gestion dynamique SQL Server liées au système d'exploitation (Transact-SQL).

E/S disque

Le gestionnaire de tampons n'effectue que des lectures et des écritures dans la base de données. Les autres opérations de base de données et de fichier comme les opérations d'ouverture, de fermeture, d'élargissement et de compactage sont prises en charge par les composants du gestionnaire de base de données et du gestionnaire de fichiers.

Les opérations d'E/S disque effectuées par le gestionnaire de tampons présentent les caractéristiques suivantes :

  • Toutes les opérations d'E/S s'effectuent de manière asynchrone, ce qui permet au thread appelant de continuer le traitement durant l'opération d'E/S en arrière-plan.

  • Toutes les opérations d'E/S ont lieu dans les threads appelants sauf si l'option affinity I/O est utilisée. L'option affinity I/O mask lie les E/S disque de SQL Server à un sous-ensemble de processeurs spécifié. Dans les environnements de traitement transactionnel en ligne (OLTP) SQL Server haut de gamme, cette extension permet d'améliorer les performances des threads SQL Server émettant des E/S.

  • Les E/S de pages multiples s'effectuent à l'aide d'E/S par fragmentation-rassemblement, ce qui permet le transfert des données dans des zones contiguës de la mémoire ou hors de celles-ci. Cela signifie que SQL Server peut remplir ou vider rapidement le cache de tampons tout en évitant les demandes d'E/S physiques multiples.

Longues demandes d'E/S

Le gestionnaire de tampons signale les demandes d'E/S en suspens pendant un délai minimum de 15 secondes. L'administrateur système peut ainsi distinguer entre les problèmes SQL Server et les problèmes au niveau du sous-système d'E/S. Le message d'erreur 833 est rapporté et consigné dans le journal des erreurs SQL Server comme suit :

SQL Server a rencontré %d occurrence(s) de requêtes d'E/S mettant plus de %d secondes à s'effectuer dans le fichier [%ls] de la base de données [%ls] (%d). Le descripteur de fichier du système d'exploitation est 0x%p. Le décalage de la dernière E/S longue est : %#016I64x.

Une longue opération d'E/S peut correspondre à une opération de lecture ou d'écriture ; celle-ci ne figure pas dans le message actif. Les messages d'opérations d'E/S longues sont des avertissements pas des erreurs. Ils n'indiquent pas de problèmes avec SQL Server. Les messages permettent à l'administrateur de détecter la cause des temps de réponse SQL Server médiocres plus rapidement et de distinguer les problèmes qui ne dépendent pas de SQL Server. De ce fait, ces problèmes ne demandent aucune intervention, mais il est nécessaire que l'administrateur système analyse les raisons de la lenteur de la demande d'E/S et si ce délai est justifié.

Facteurs de longues demandes d'E/S

Un message d'une opération d'E/S longue peut indiquer qu'une E/S est bloquée de manière permanente et ne peut s'achever (E/S perdue) ou qu'elle ne s'est pas encore terminée. Il est impossible d'identifier le type de scénario à partir du message, même si une E/S perdue entraîne souvent un délai d'attente de verrou.

Une opération d'E/S longue indique souvent une charge de travail SQL Server trop intense pour le sous-système de disque. Un sous-système de disque inapproprié peut se manifester dans les cas suivants :

  • plusieurs opérations d'E/S longues dans le journal d'erreurs au cours d'une charge SQL Server importante ;

  • les compteurs de performance indiquent des latences de disque longues, des files d'attente de disque longues ou pas d'inactivité de disque.

Les opérations d'E/S longues sont aussi parfois causées par un composant dans le chemin d'accès d'E/S (un pilote, un contrôleur, un microprogramme, entre autres) qui retardent continuellement une demande d'E/S antérieure pour traiter des demandes plus récentes dont la position actuelle est plus proche de la tête de disque. La technique courante de traitement prioritaire des demandes en fonction de la proximité de celles-ci de la tête de lecture-écriture est connue sous le nom de « elevator seeking ». Cette technique peut ne pas être compatible avec l'outil Moniteur système Windows (PERFMON.EXE) en raison du traitement rapide de la plupart des E/S. Les opérations d'E/S longues peuvent se compliquer en raison de charges de travail impliquant de grandes quantités d'E/S séquentielle, parmi lesquelles figurent les opérations de sauvegarde et de restauration, les analyses de table, les tris, les créations d'index, les chargements en masse et les réinitialisations de fichiers.

Les opérations d'E/S longues isolées qui ne présentent à priori aucun rapport avec les conditions décrites plus haut sont peut-être causées par un problème de matériel ou de pilote. Le journal d'événements système peuvent contenir un événement connexe qui permet de diagnostiquer le problème.

Détection d'erreurs

Les pages de base de données peuvent faire appel à deux mécanismes facultatifs qui permettent de garantir l'intégrité de la page depuis son écriture sur le disque à sa relecture : les protections de la somme de contrôle et de la page endommagée. Ces mécanismes offrent une méthode indépendante de vérification de l'exactitude du stockage des données ainsi que des composants matériels tels que les contrôleurs, les pilotes, les câbles et même le système d'exploitation. La protection est ajoutée à la page juste avant l'écriture sur le disque, puis elle est vérifiée après sa lecture sur le disque.

Protection de page endommagée

La Protection de page endommagée, introduite dans SQL Server 2000, est essentiellement une méthode de détection des pages endommagées causées par les pannes d'alimentation. Par exemple, une panne d'alimentation inattendue peut n'entraîner que l'écriture partielle d'une page sur le disque. Grâce à la protection de page endommagée, une signature de 2 bits est placée à la fin de chaque secteur de 512 octets dans la page (après la copie des deux bits d'origine dans l'en-tête de la page). La signature alterne entre des 01 et 10 binaires à chaque écriture, ainsi il est toujours possible de savoir si seule une partie des secteurs a été écrite sur le disque : si un bit est dans le mauvais état lors de la lecture ultérieure de la page, celle-ci a été écrite de manière incorrecte et une page endommagée est détectée. Ce type de détection fait appel à des ressources minimales ; cependant, elle ne détecte pas toutes les erreurs causées par les pannes de matériel des disques.

Protection de la somme de contrôle

La protection de la somme de contrôle, introduite dans SQL Server 2005, fournit une vérification renforcée de l'intégrité des données. Une somme de contrôle est calculée pour les données de chaque page écrite, elle est stockée dans l'en-tête de page. À chaque lecture d'une page contenant une somme de contrôle stockée sur le disque, le moteur de la base de données recalcule la somme de contrôle pour les données de la page et renvoie l'erreur 824 si la nouvelle somme de contrôle n'est pas identique à la somme de contrôle stockée. La protection de la somme de contrôle peut détecter un plus grand nombre d'erreurs que la protection de page endommagée car celle-ci est affectée par chaque octet de la page, elle utilise toutefois peu de ressources. Lorsque la somme de contrôle est activée, les erreurs causées par les pannes d'alimentation et du matériel ou des microprogrammes défectueux sont détectables à chaque lecture d'une page sur le disque par le gestionnaire de tampons.

Le type de protection de page utilisé est un attribut de la base de données qui contient la page. La protection de la somme de contrôle est la protection par défaut pour les bases de données créées dans SQL Server 2005 et les versions ultérieures. Le mécanisme de protection de page est spécifié au moment de la création de la base de données et peut être modifié à l'aide de ALTER DATABASE. Vous pouvez déterminer le paramètre de protection de page en cours en interrogeant la colonne page_verify_option de l'affichage catalogue sys.databases ou la propriété IsTornPageDetectionEnabled de la fonction DATABASEPROPERTYEX. En cas de modification du paramètre de protection de page, le nouveau paramètre ne prend pas immédiatement effet dans l'ensemble de la base de données. Par contre, les pages adoptent le niveau de protection en cours de la base de données lors de leur écriture ultérieure. Cela signifie que la base de données peut contenir des pages utilisant différents types de protection.