Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
s’applique à :
SQL ServerAzure SQL Managed Instance
Les E/S d’une instance du moteur de base de données SQL Server incluent les lectures logiques et physiques. Une lecture logique se produit chaque fois que le moteur de base de données demande une page à partir du cache de mémoire tampon, également appelée pool de mémoires tampons. Si la page n’est pas actuellement dans le cache de mémoire tampon, une lecture physique copie d’abord la page à partir du disque dans le cache.
Les demandes de lecture générées par une instance du moteur de base de données sont contrôlées par le moteur relationnel et optimisées par le moteur de stockage. Le moteur relationnel détermine la méthode d’accès la plus efficace (par exemple, une analyse de table, une analyse d’index ou une lecture à clé). Les méthodes d’accès et les composants du gestionnaire de mémoire tampon du moteur de stockage déterminent le modèle général des lectures à effectuer et optimisent les lectures requises pour implémenter la méthode d’accès. Le thread exécutant le traitement par lots planifie les lectures.
Lecture anticipée
Le moteur de base de données prend en charge un mécanisme d’optimisation des performances appelé lecture anticipée. La lecture anticipée prévoit les données et les pages d'index nécessaires à l'exécution d'un plan de requête, et amène les pages dans le cache de mémoire tampon avant qu'elles ne soient utilisées par la requête. Ce processus permet au calcul et aux E/S de se chevaucher, en tirant pleinement parti de l’UC et du disque.
Le mécanisme en lecture-avance permet au moteur de base de données de lire jusqu’à 64 pages contiguës (512 Ko) à partir d’un fichier. La lecture est une lecture unique par ventilation-regroupement du nombre approprié de mémoires tampons (probablement non contiguës) dans le pool de mémoires tampons. Si l’une des pages de la plage est déjà présente dans le cache de mémoire tampon, la page correspondante de la lecture est ignorée une fois la lecture terminée. La plage de pages peut également être « supprimée » de l’une ou l’autre des extrémités si les pages correspondantes sont déjà présentes dans le cache.
Il existe deux types de lecture anticipée : une pour les pages de données et une pour les pages d’index.
Lire les pages de données
Les analyses de table utilisées par le moteur de base de données pour lire les pages de données sont efficaces. Les pages IAM (Index Allocation Map) d’une base de données SQL Server dressent la liste des étendues utilisées par une table ou un index. Le moteur de stockage peut lire la page IAM afin d'établir une liste des adresses de disques qui doivent être lues. Cela permet au moteur de stockage d'optimiser ses E/S sous la forme d'importantes lectures séquentielles en fonction de leur emplacement sur le disque. Pour plus d’informations sur les pages IAM, consultez Gérer l’espace utilisé par les objets.
Lire les pages d’index
Le moteur de stockage lit les pages d'index en série selon l'ordre des clés. Par exemple, l'illustration ci-dessous montre une représentation simplifiée d'un ensemble de pages d'arborescence contenant un ensemble de clés et le nœud d'index intermédiaire mappant les pages de l'arborescence. Pour plus d’informations sur la structure des pages d’un index, consultez les index clusterisés et non-clusterisés.
Le moteur de stockage utilise les informations de la page d'index intermédiaire au-dessus du niveau des feuilles pour planifier les lectures anticipées en série des pages contenant les clés. Si une demande est effectuée pour toutes les clés de ABC à DEF, le moteur de stockage lit d’abord la page d’index au-dessus de la page feuille. Toutefois, il ne lit pas simplement chaque page de données en séquence de la page 504 à la page 556 (la dernière page avec des clés dans la plage spécifiée). Au lieu de cela, le moteur de stockage analyse la page d'index intermédiaire et génère la liste des pages feuille qui doivent être lues. Le moteur de stockage planifie alors toutes les lectures dans l'ordre des clés. Le moteur de stockage reconnaît également que les pages 504/505 et 527/528 sont contiguës et effectue une seule lecture par ventilation pour extraire les pages adjacentes en une seule opération. Lorsque plusieurs pages doivent être extraites par une opération en série, le moteur de stockage planifie un bloc de lectures à la fois. Lorsqu’un sous-ensemble de ces lectures est terminé, le moteur de stockage planifie un nombre égal de nouvelles lectures jusqu’à ce que toutes les lectures requises soient planifiées.
Le moteur de stockage utilise la pré-extraction pour accélérer la recherche de table de consultation dans les index non-cluster. Les lignes feuille d'un index non-cluster contiennent des pointeurs vers les lignes de données contenant chaque valeur de clé spécifique. Lorsque le moteur de stockage lit les pages feuille de l’index non-cluster, il planifie également les lectures asynchrones des lignes de données dont les pointeurs ont déjà été extraits. Cela permet au moteur de stockage de récupérer les lignes de données de la table sous-jacente avant de terminer l’analyse de l’index non cluster. La pré-extraction est utilisée que la table possède ou non un index cluster. L’édition SQL Server Enterprise utilise plus de prérécupération que d’autres éditions de SQL Server, ce qui permet de lire davantage de pages. Le niveau de pré-extraction ne peut être configuré dans aucune édition. Pour plus d'informations sur les index non-clusterisés, consultez Les index clusterisés et non-clusterisés.
Analyse avancée
Dans l’édition SQL Server Enterprise, la fonctionnalité d’analyse avancée permet à plusieurs tâches de partager des analyses complètes de table. Si le plan d’exécution d’une instruction Transact-SQL exige une analyse des pages de données d’une table et le moteur de base de données détecte que la table est déjà en cours d’analyse pour un autre plan d’exécution, le moteur de base de données joint la deuxième analyse à la première, à l’emplacement actuel de la deuxième analyse. Le moteur de base de données lit chaque page une fois et transmet les lignes de chacune des pages aux deux plans d’exécution. Ce processus se poursuit jusqu'à ce que la fin de la table soit atteinte.
À ce stade, le premier plan d’exécution a les résultats complets d’une analyse. Toutefois, le deuxième plan d’exécution doit toujours récupérer les pages de données lues avant de joindre l’analyse en cours. L'analyse du second plan d'exécution revient alors à la première page de données de la table et poursuit l'analyse jusqu'au point de jonction avec la première analyse. Un nombre quelconque d'analyses peuvent ainsi être combinées. Le moteur de base de données continue à parcourir les pages de données jusqu’à ce qu’il termine toutes les analyses. Ce mécanisme est également appelé « analyse de merry-go-round » et montre pourquoi l’ordre des résultats retournés par une SELECT instruction ne peut pas être garanti sans ORDER BY clause.
Supposons par exemple que vous disposiez d'une table de 500 000 pages. UserA exécute une instruction Transact-SQL qui nécessite une analyse de la table. Lorsque cette analyse a traité 100 000 pages, UserB exécute une autre instruction Transact-SQL qui analyse la même table. Le moteur de base de données planifie un ensemble de requêtes de lectures pour les pages à partir de la 100 001e et transmet les lignes de chaque page aux deux analyses. Lorsque l’analyse atteint la 200 000e page, UserC exécute une autre instruction Transact-SQL qui analyse la même table. En commençant par la page 200 001, le moteur de base de données transmet les lignes de chaque page lue aux trois analyses. Une fois qu'elle a lu la 500 000e ligne, l'analyse pour UserA est terminée, et les analyses pour UserB et UserC reprennent et commencent à lire les pages en commençant par la page 1. Lorsque le moteur de base de données arrive à la page 100 000, l'analyse pour UserB est complétée. L’analyse pour UserC continue seule jusqu’à atteindre la page 200 000. À ce stade, toutes les analyses sont terminées.
Sans analyse avancée, chaque utilisateur doit se battre pour utiliser l'espace tampon et causer des contentions de disque. Les mêmes pages sont alors probablement lues une fois pour chaque utilisateur, plutôt que d'être lues une fois et partagées entre plusieurs utilisateurs, ce qui ralentit les performances et consomme des ressources.