Partager via

Diagnostiquer et dépanner les processeurs élevés sur la Base de données Azure SQL et les bases de données SQL dans Microsoft Fabric

  • Article

S’applique à : Base de données Azure SQL Base de données SQL dans Fabric

Base de données SQL et Base de données SQL dans Fabric fournissent des outils intégrés pour identifier les causes d'une utilisation élevée de l'unité centrale et pour optimiser les performances de la charge de travail. Vous pouvez utiliser ces outils pour résoudre des problèmes d’utilisation élevée de l’UC lorsqu’il se produit ou de façon réactive une fois l’incident terminé. Vous pouvez également activer le réglage automatique pour réduire de façon proactive l’utilisation de l’UC au fil du temps pour votre base de données. Cet article vous explique comment diagnostiquer et résoudre des problèmes liés à l’utilisation élevée de l’UC à l’aide d’outils intégrés dans Azure SQL Database et explique quand ajouter des ressources de l’UC.

Comprendre le nombre de mémoires à tores magnétiques virtuelles

Il est utile de comprendre le nombre de mémoires à tores magnétiques virtuelles (vCore) disponibles pour votre base de données lors du diagnostic d’un incident de processeur élevé. Un vCore est équivalent à un processeur logique. Le nombre de vCores vous aide à comprendre les ressources de l’UC disponibles pour votre base de données.

Identifier le nombre de mémoires à tores magnétiques virtuelles dans le Portail Azure

Vous pouvez rapidement identifier le nombre de mémoires à tores magnétiques virtuelles d’une base de données dans le Portail Azure si vous utilisez un niveau de service basé sur la mémoire à tores magnétiques virtuelle avec le niveau de calcul provisioné. Dans ce cas, le niveau de tarification répertorié pour la base de données sur sa page Vue d’ensemble contiendra le nombre de mémoires à tores magnétiques virtuelles. Par exemple, le niveau de tarification d’une base de données peut être « Usage général : série Standard (Gen5), 16 vCores ».

Pour les bases de données au niveau de calcul serverless, le nombre de mémoires à tores magnétiques virtuelles sera toujours équivalent au paramètre vCore maximal pour la base de données. Le nombre de vCores s’affiche dans le niveau de tarification répertorié pour la base de données sur sa page Vue d’ensemble. Par exemple, le niveau de tarification d’une base de données peut être « Usage général : Serverless, série Standard (Gen5), 16 vCores ».

Si vous utilisez une base de données sous le modèle d’achat DTU, vous devez utiliser Transact-SQL pour interroger le nombre de vCores de la base de données.

Identifier le nombre de vCores avec Transact-SQL

Vous pouvez identifier le nombre de vCores actuel pour n’importe quelle base de données avec Transact-SQL. Vous pouvez exécuter Transact-SQL par rapport à la base de données Azure SQL avec SQL Server Management Studio (SSMS), Azure Data Studio ou l’éditeur de requêtes du portail Azure.

Connectez-vous à votre base de données et exécutez la requête suivante :

SELECT 
    COUNT(*) as vCores
FROM sys.dm_os_schedulers
WHERE status = N'VISIBLE ONLINE';
GO

Identifier les causes d’un processeur élevé

Vous pouvez mesurer et analyser l’utilisation de l’UC à l’aide du Portail Azure, des outils interactifs du Magasin des requêtes dans SSMS et des requêtes Transact-SQL dans SSMS et Azure Data Studio.

Le Portail Azure et le Magasin des requêtes montrent les statistiques d’exécution, telles que les mesures UC, pour les requêtes terminées. Si vous rencontrez actuellement un incident d’utilisation élevée de l’UC qui peut être dû à des requêtes de longue durée, identifiez les requêtes en cours d’exécution avec Transact-SQL.

Les causes courantes de l’utilisation d’un processeur nouveau et inhabituel élevé sont les suivantes :

  • Nouvelles requêtes dans la charge de travail qui utilisent un volume important d’UC.
  • Augmentation de la fréquence d’exécution régulière de requêtes.
  • Régression du plan de requête, y compris la régression due à des problèmes de plan sensible aux paramètres (PSP), ce qui entraîne une ou plusieurs requêtes qui consomment plus d’UC.
  • Une augmentation significative de la compilation ou de la recompilation des plans de requête.
  • Bases de données où les requêtes utilisent un parallélisme excessif.

Pour comprendre ce qui est à l’origine de votre incident d’UC élevé, identifiez quand l’utilisation élevée du processeur se produit sur votre base de données et les principales requêtes utilisant l’UC à ce moment-là.

Examinez :

Remarque

Azure SQL Database nécessite des ressources de calcul pour implémenter des fonctionnalités de service de base telles que la haute disponibilité et la récupération d’urgence, la sauvegarde et la restauration de bases de données, la surveillance, le Magasin des requêtes, le réglage automatique, etc. L’utilisation de ces ressources informatiques peut être particulièrement évidente si le nombre de vCores est faible ou sur les bases de données dans des pools élastiques denses. En savoir plus sur la Gestion des ressources dans Azure SQL Database.

Utilisez le Portail Azure pour suivre différentes mesures d’UC, notamment le pourcentage d’UC disponible utilisé par votre base de données au fil du temps. Le Portail Azure combine les mesures d’UC avec les informations du Magasin des requêtes de votre base de données, ce qui vous permet d’identifier les requêtes qui ont été consommées dans votre base de données à un moment donné.

Pour trouver des mesures de pourcentage d’UC, suivez ces étapes.

  1. Accédez à la base de données dans le Portail Azure.
  2. Dans le menu de gauche, sous Performances intelligentes, sélectionnez Query Performance Insight.

L’affichage par défaut de Query Performance Insight affiche 24 heures de données. L’utilisation de l’UC est représentée par le pourcentage du total de l’UC disponible utilisé pour la base de données.

Les cinq principales requêtes qui s’exécutent au cours de cette période sont affichées dans des barres verticales au-dessus du graphique d’utilisation de l’UC. Sélectionnez une bande d’heures sur le graphique ou utilisez le menuPersonnaliser pour explorer des périodes spécifiques. Vous pouvez également augmenter le nombre de requêtes affichées.

Capture d’écran représentant Query Performance Insight dans le Portail Azure.

Sélectionnez chaque ID de requête présentant un processeur élevé pour ouvrir les détails de la requête. Les détails incluent le texte de la requête, ainsi que l’historique du niveau de performance de la requête. Vérifiez si l’UC a récemment augmenté pour la requête.

Notez l’ID de la requête pour examiner le plan de requête à l’aide du Magasin des requêtes dans la section suivante.

Examinez les plans de requête pour les principales requêtes identifiées dans le Portail Azure

Suivez ces étapes pour utiliser un ID de requête dans les outils SSMS du Magasin des requêtes interactifs pour examiner le plan d’exécution de la requête dans le temps.

  1. Ouvrez SSMS.
  2. Connectez-vous à votre Azure SQL Database dans l’Explorateur d’objets.
  3. Développez le nœud de bases de données dans l’Explorateur d’objets.
  4. Développez le dossier Magasin des requêtes.
  5. Ouvrez le volet Requêtes avec suivi.
  6. Entrez l’ID de requête dans la boîte Suivi de la requête en haut à gauche de l’écran, puis appuyez sur Entrée.
  7. Si nécessaire, sélectionnez Configurer pour ajuster l’intervalle de temps de façon à ce qu’il corresponde à l’heure de l’utilisation élevée de l’UC.

La page affiche le ou les plans d’exécution et les mesures associées pour la requête au cours des dernières 24 heures.

Identifier les requêtes en cours d’exécution avec Transact-SQL

Transact-SQL vous permet d’identifier les requêtes en cours d’exécution avec le temps processeur utilisé jusqu’à présent. Vous pouvez également utiliser Transact-SQL pour interroger l’utilisation récente de l’UC dans votre base de données, les principales requêtes par UC et les requêtes les plus fréquemment compilées.

Vous pouvez interroger les mesures d’UC avec SQL Server Management Studio (SSMS), Azure Data Studio ou l’éditeur de requêtes du Portail Azure. Quand vous utilisez SSMS ou Azure Data Studio, ouvrez une nouvelle fenêtre de requête et connectez-la à votre base de données (pas la base de données master).

Recherchez les requêtes en cours d’exécution avec des plans d’utilisation et d’exécution de l’UC en exécutant la requête suivante. Le temps processeur est renvoyé en millisecondes.

SELECT
    req.session_id,
    req.status,
    req.start_time,
    req.cpu_time AS 'cpu_time_ms',
    req.logical_reads,
    req.dop,
    s.login_name,
    s.host_name,
    s.program_name,
    object_name(st.objectid,st.dbid) 'ObjectName',
    REPLACE (REPLACE (SUBSTRING (st.text,(req.statement_start_offset/2) + 1,
        ((CASE req.statement_end_offset    WHEN -1    THEN DATALENGTH(st.text) 
        ELSE req.statement_end_offset END - req.statement_start_offset)/2) + 1),
        CHAR(10), ' '), CHAR(13), ' ') AS statement_text,
    qp.query_plan,
    qsx.query_plan as query_plan_with_in_flight_statistics
FROM sys.dm_exec_requests as req  
JOIN sys.dm_exec_sessions as s on req.session_id=s.session_id
CROSS APPLY sys.dm_exec_sql_text(req.sql_handle) as st
OUTER APPLY sys.dm_exec_query_plan(req.plan_handle) as qp
OUTER APPLY sys.dm_exec_query_statistics_xml(req.session_id) as qsx
ORDER BY req.cpu_time desc;
GO

Cette requête renvoie deux copies du plan d’exécution. La colonne query_plan contient le plan d’exécution de sys.dm_exec_query_plan. Cette version du plan de requête contient uniquement des estimations du nombre de lignes et ne contient aucune statistique d’exécution.

Si la colonne query_plan_with_in_flight_statistics renvoie un plan d’exécution, ce plan fournit des informations supplémentaires. La colonne query_plan_with_in_flight_statistics renvoie des données de sys.dm_exec_query_statistics_xml, qui inclut des statistiques d’exécution « en mode Flighting », telles que le nombre réel de lignes renvoyées jusqu’à présent par une requête en cours d’exécution.

Examiner les métriques d'utilisation de l’UC pour la dernière heure

La requête suivante sur sys.dm_db_resource_stats renvoie l’utilisation moyenne de l’UC sur des intervalles de 15 secondes pendant environ la dernière heure.

SELECT
    end_time,
    avg_cpu_percent,
    avg_instance_cpu_percent
FROM sys.dm_db_resource_stats
ORDER BY end_time DESC; 
GO

Il est important de ne pas se concentrer uniquement sur la colonneavg_cpu_percent. La colonne avg_instance_cpu_percent inclut l’UC utilisée par les charges de travail utilisateur et interne. Si avg_instance_cpu_percent est proche de 100 %, les ressources de l’UC sont saturées. Dans ce cas, vous devez résoudre un taux élevé d’UC si le débit d’application est insuffisant ou si la latence des requêtes est élevée.

En savoir plus sur la Gestion des ressources dans Azure SQL Database.

Consultez les exemples dans sys.dm_db_resource_stats pour afficher plus de requêtes.

Interroger les 15 requêtes les plus récentes par utilisation de l’UC

Le magasin des requêtes suit les statistiques d’exécution, y compris l’utilisation de l’UC, pour les requêtes. La requête suivante renvoie les 15 principales requêtes qui s’exécutent au cours des 2 dernières heures, triées par utilisation de l’UC. Le temps processeur est renvoyé en millisecondes.

WITH AggregatedCPU AS 
    (SELECT
        q.query_hash, 
        SUM(count_executions * avg_cpu_time / 1000.0) AS total_cpu_ms, 
        SUM(count_executions * avg_cpu_time / 1000.0)/ SUM(count_executions) AS avg_cpu_ms, 
        MAX(rs.max_cpu_time / 1000.00) AS max_cpu_ms, 
        MAX(max_logical_io_reads) max_logical_reads, 
        COUNT(DISTINCT p.plan_id) AS number_of_distinct_plans, 
        COUNT(DISTINCT p.query_id) AS number_of_distinct_query_ids, 
        SUM(CASE WHEN rs.execution_type_desc='Aborted' THEN count_executions ELSE 0 END) AS aborted_execution_count, 
        SUM(CASE WHEN rs.execution_type_desc='Regular' THEN count_executions ELSE 0 END) AS regular_execution_count, 
        SUM(CASE WHEN rs.execution_type_desc='Exception' THEN count_executions ELSE 0 END) AS exception_execution_count, 
        SUM(count_executions) AS total_executions, 
        MIN(qt.query_sql_text) AS sampled_query_text
    FROM sys.query_store_query_text AS qt
    JOIN sys.query_store_query AS q ON qt.query_text_id=q.query_text_id
    JOIN sys.query_store_plan AS p ON q.query_id=p.query_id
    JOIN sys.query_store_runtime_stats AS rs ON rs.plan_id=p.plan_id
    JOIN sys.query_store_runtime_stats_interval AS rsi ON rsi.runtime_stats_interval_id=rs.runtime_stats_interval_id
    WHERE 
            rs.execution_type_desc IN ('Regular', 'Aborted', 'Exception') AND 
        rsi.start_time>=DATEADD(HOUR, -2, GETUTCDATE())
     GROUP BY q.query_hash), 
OrderedCPU AS 
    (SELECT *, 
    ROW_NUMBER() OVER (ORDER BY total_cpu_ms DESC, query_hash ASC) AS RN
    FROM AggregatedCPU)
SELECT *
FROM OrderedCPU AS OD
WHERE OD.RN<=15
ORDER BY total_cpu_ms DESC;
GO

Cette requête se regroupe par valeur de synthèse de la requête. Si vous trouvez une valeur élevée dans la colonne number_of_distinct_query_ids, examinez si une requête fréquemment exécutée n’est pas correctement paramétrée. Les requêtes non paramétrables peuvent être compilées sur chaque exécution, ce qui entraîne une consommation élevée du processeur et affecte les performances du Magasin des requêtes.

Pour en savoir plus sur une requête individuelle, notez la synthèse de la requête et utilisez-la pour identifier le plan d’utilisation et de requête de l’UC pour une synthèse de la requête donnée.

Interroger les requêtes les plus fréquemment compilées par synthèse de requête

La compilation d’un plan de requête est un processus qui demande de l’UC. Azure SQL Database met en cache des plans en mémoire pour une réutilisation. Certaines requêtes peuvent être fréquemment compilées si elles ne sont pas paramétrables ou si des indicateurs RECOMPILE imposent la recompilation.

Le magasin des requêtes suit le nombre de fois où les requêtes sont compilées. Exécutez la requête suivante pour identifier les 20 principales requêtes du magasin des requêtes par nombre de compilations, ainsi que le nombre moyen de compilations par minute :

SELECT TOP (20)
    query_hash,
    MIN(initial_compile_start_time) as initial_compile_start_time,
    MAX(last_compile_start_time) as last_compile_start_time,
    CASE WHEN DATEDIFF(mi,MIN(initial_compile_start_time), MAX(last_compile_start_time)) > 0
        THEN 1.* SUM(count_compiles) / DATEDIFF(mi,MIN(initial_compile_start_time), 
            MAX(last_compile_start_time)) 
        ELSE 0 
        END as avg_compiles_minute,
    SUM(count_compiles) as count_compiles
FROM sys.query_store_query AS q
GROUP BY query_hash
ORDER BY count_compiles DESC;
GO

Pour en savoir plus sur une requête individuelle, notez la synthèse de la requête et utilisez-la pour identifier le plan d’utilisation et de requête de l’UC pour une synthèse de la requête donnée.

Identifier le plan d’utilisation et de requête de l’UC pour une synthèse de la requête donnée

Exécutez la requête suivante pour rechercher l’ID de la requête individuel, le texte de la requête et les plans d’exécution d’une requête pour une query_hash donnée. Le temps processeur est renvoyé en millisecondes.

Remplacez la valeur de la variable @query_hash par une valeur validequery_hash pour votre charge de travail.

declare @query_hash binary(8);

SET @query_hash = 0x6557BE7936AA2E91;

with query_ids as (
    SELECT
        q.query_hash,
        q.query_id,
        p.query_plan_hash,
        SUM(qrs.count_executions) * AVG(qrs.avg_cpu_time)/1000. as total_cpu_time_ms,
        SUM(qrs.count_executions) AS sum_executions,
        AVG(qrs.avg_cpu_time)/1000. AS avg_cpu_time_ms
    FROM sys.query_store_query q
    JOIN sys.query_store_plan p on q.query_id=p.query_id
    JOIN sys.query_store_runtime_stats qrs on p.plan_id = qrs.plan_id
    WHERE q.query_hash = @query_hash
    GROUP BY q.query_id, q.query_hash, p.query_plan_hash)
SELECT qid.*,
    qt.query_sql_text,
    p.count_compiles,
    TRY_CAST(p.query_plan as XML) as query_plan
FROM query_ids as qid
JOIN sys.query_store_query AS q ON qid.query_id=q.query_id
JOIN sys.query_store_query_text AS qt on q.query_text_id = qt.query_text_id
JOIN sys.query_store_plan AS p ON qid.query_id=p.query_id and qid.query_plan_hash=p.query_plan_hash
ORDER BY total_cpu_time_ms DESC;
GO

Cette requête renvoie une ligne pour chaque variante d’un plan d’exécution pour l’ensemble de l’historique de la query_hash de votre magasin des requêtes. Les résultats sont triés par durée totale de l’UC.

Utiliser les outils du magasin des requêtes interactifs pour suivre l’utilisation historique de l’UC

Si vous préférez utiliser des outils graphiques, suivez ces étapes pour utiliser les outils interactifs du magasin des requêtes dans SSMS.

  1. Ouvrez SSMS et connectez-vous à votre base de données dans l’Explorateur d’objets.
  2. Développez le nœud de bases de données dans l’Explorateur d'objets
  3. Développez le dossier Magasin des requêtes.
  4. Ouvrez le volet Consommation globale des ressources.

Le temps total de l’UC pour votre base de données sur le mois dernier en millisecondes s’affiche dans la partie inférieure gauche du volet. Dans l’affichage par défaut, le temps de l’UC est agrégé par jour.

Capture d’écran affichant l’affichage de consommation globale des ressources dans le Magasin des requêtes de SSMS.

Sélectionnez Configurer dans la partie supérieure droite du volet pour sélectionner une autre période. Vous pouvez également modifier l’unité d’agrégation. Par exemple, vous pouvez choisir d’afficher les données d’une plage de dates spécifique et d’agréger les données par heure.

Utiliser les outils interactifs du Magasin des requêtes pour identifier les principales requêtes par temps processeur

Sélectionnez une barre dans le graphique pour consulter les requêtes en cours d’exécution au cours d’une période spécifique. Le volet Principales requêtes consommatrices de ressources s’ouvre. Vous pouvez également ouvrir Principales requêtes consommatrices de ressources à partir du nœud Magasin des requêtes sous votre base de données directement dans l’Explorateur d’objets.

Capture d’écran représentant le volet Principales requêtes consommatrices de ressources dans le Magasin des requêtes de SSMS.

Dans l’affichage par défaut, le volet Principales requêtes consommatrices de ressources affiche les requêtes par Durée (ms). La durée peut parfois être inférieure au temps processeur : les requêtes utilisant le parallélisme peuvent utiliser beaucoup plus de temps processeur que leur durée globale. La durée peut également être supérieure au temps processeur si les temps d’attente sont importants. Pour voir les requêtes par temps processeur, sélectionnez le menu déroulant Métrique en haut à gauche du volet, puis sélectionnez Temps processeur (ms).

Chaque barre dans le quadrant supérieur gauche représente une requête. Sélectionnez une barre pour voir les détails de cette requête. Le quadrant supérieur droit de l’écran indique combien de plans d’exécution sont mis en place dans le Magasin de requêtes pour cette requête et les mappe en fonction du moment où ils ont été exécutés et de la quantité de métriques sélectionnées utilisée. Sélectionnez chaque ID de plan pour contrôler le plan d’exécution des requêtes qui s’affiche dans la moitié inférieure de l’écran.

Notes

Pour consulter un guide d’interprétation des affichages du Magasin des requêtes et des formes qui apparaissent dans l’affichage Consommateurs de ressources, consultez Meilleures pratiques avec le Magasin des requêtes

Réduire l’utilisation de l’UC

Une partie de votre résolution des problèmes doit inclure des informations supplémentaires sur les requêtes identifiées dans la section précédente. Vous pouvez réduire l’utilisation de l’UC en modifiant les index, en modifiant les modèles d’application, en adaptant les requêtes et en ajustant les paramètres liés à l’UC pour votre base de données.

Envisageons les stratégies suivantes dans cette section.

Réduire l’utilisation de l’UC avec le réglage automatique des index

Le réglage efficace des index permet de réduire l’utilisation de l’UC pour de nombreuses requêtes. Les index optimisés réduisent les lectures logiques et physiques d’une requête, ce qui entraîne souvent moins de travail pour la requête.

Azure SQL Database offre une gestion automatique des index des charges de travail sur les réplicas principaux. La gestion automatique des index utilise le Machine Learning pour surveiller votre charge de travail et optimiser les index non cluster basés sur le disque du rowstore pour votre base de données.

Examinez les suggestions de niveau de performance y compris les suggestions d’index, dans le Portail Azure. Vous pouvez appliquer ces suggestions manuellement ou activer l’option DE réglage automatique CREATE INDEX pour créer et vérifier le niveau de performance des nouveaux index dans votre base de données.

Réduire l’utilisation de l’UC avec la correction automatique du plan (plan de force)

Une autre cause fréquente d’incidents d’UC est la régression du choix de plan d’exécution. Azure SQL Database offre l’option de réglage automatique du plan de force pour identifier les régressions dans les plans d’exécution de requête dans les charges de travail sur les réplicas principaux. Avec cette fonctionnalité de réglage automatique activée, Azure SQL Database testera si forcer un plan d’exécution de requête entraîne un niveau de performance amélioré fiable pour les requêtes avec une régression du plan d’exécution.

Si votre base de données a été créée après mars 2020, l’option de réglage automatique du plan de force a été automatiquement activée. Si votre base de données a été créée avant, vous pouvez activer l’option permettant de forcer le réglage automatique du plan.

Régler les index manuellement

Utilisez les méthodes décrites dans Identifier les causes du taux élevé d’UC pour identifier les plans de requête pour vos principales requêtes consommatrices d’UC. Ces plans d’exécution vous aideront à identifier et à ajouter des index non cluster pour accélérer vos requêtes.

Chaque index non cluster basé sur un disque dans votre base de données requiert de l’espace de stockage et doit être conservé par le moteur SQL. Modifiez des index existants au lieu d’ajouter de nouveaux index le cas échéant et assurez-vous que les nouveaux index réduisent correctement l’utilisation de l’UC. Pour une vue d’ensemble des index non cluster, consutez les directives de conception des index non cluster.

Pour certaines charges de travail, les index columnstore sont idéaux pour réduire l’utilisation du processeur lors de requêtes en lecture fréquente. Consultez Index columnstore – Aide à la conception pour obtenir des recommandations générales concernant les scénarios dans lesquels les index columnstore peuvent être appropriés.

Régler votre application, vos requêtes et vos paramètres de base de données

Lors de l’examen de vos principales requêtes, vous trouverez peut-être des antimodèles d’application tels qu’un comportement « bavard », des charges de travail qui pourraient bénéficier du partitionnement et une conception non optimale de l’accès à la base de données. Pour les charges de travail à lecture intensive, envisagez des réplicas en lecture seule pour décharger les charges de travail des requêtes en lecture seule et la mise en cache au niveau des applications comme stratégies à long terme pour mettre à l’échelle les données fréquemment lues.

Vous pouvez également régler manuellement les requêtes de votre charge de travail qui utilisent le plus le processeur. Les options de réglage manuel incluent la réécriture d’instructions Transact-SQL, en forçant les plans dans le Magasin des requêtes et l’application d’indicateurs de requête.

Si vous identifiez des cas dans lesquels des requêtes utilisent parfois un plan d’exécution qui n’est pas optimal en matière de performances, examinez les solutions pour les requêtes confrontées à des problèmes de plan sensible aux paramètres (PSP).

Si vous identifiez des requêtes non paramétrisées avec un grand nombre de plans, envisagez de les paramétriser, en vous assurez de déclarer entièrement les types de données avec paramètres, notamment la longueur et la précision. Pour ce faire, modifiez les requêtes en créant un repère de plan pour forcer la paramétrisation d’une requête spécifique ou en activant la paramétrisation forcée au niveau de la base de données.

Si vous identifiez des requêtes avec des taux de compilation élevés, identifiez la cause de la compilation fréquente. La raison la plus courante de la compilation fréquente est les conseils RECOMPILE. Dès que possible, identifiez le moment où le conseil RECOMPILE a été ajouté et le problème qu’il était censé résoudre. Examinez si une solution alternative de réglage de niveau de performance peut être implémentée pour fournir un niveau de performance cohérent pour les requêtes en cours d’exécution sans conseil RECOMPILE.

Réduire l’utilisation de l’UC en réglant le degré maximal du parallélisme

Le paramètre dudegré maximal du parallélisme (MAXDOP) contrôle le parallélisme entre les requêtes dans le moteur de base de données. Des valeurs MAXDOP plus élevées produisent généralement plus de threads parallèles par requête et une exécution de requête plus rapide.

Dans certains cas, un grand nombre de requêtes parallèles s’exécutant simultanément peuvent ralentir une charge de travail et entraîner une utilisation élevée de l’UC. Un parallélisme excessif est le plus souvent présent dans les bases de données qui comptent un grand nombre de vCores lorsque MAXDOP est réglé sur un nombre élevé ou sur zéro. Lorsque MAXDOP est défini sur zéro, le moteur de base de données définit le nombre de planificateurs à utiliser par les threads parallèles sur le nombre total de cœurs logiques ou 64, la valeur la plus petite étant retenue.

Vous pouvez identifier le paramètre du degré maximal du parallélisme pour votre base de données avec Transact-SQL. Connectez-vous à votre base de données avec SSMS ou Azure Data Studio exécutez la requête suivante :

SELECT 
    name, 
    value, 
    value_for_secondary, 
    is_value_default 
FROM sys.database_scoped_configurations
WHERE name=N'MAXDOP';
GO

Vous pouvez faire des essais en apportant des modifications mineures dans la configuration MAXDOP au niveau de la base de données ou en modifiant des requêtes problématiques individuelles afin qu’elles utilisent une configuration MAXDOP non par défaut à l’aide d’un indicateur de requête. Pour plus d’informations, consultez les exemples dans configurer le degré maximal du parallélisme.

Quand ajouter des ressources de l’UC

Il est possible que les requêtes et index de votre charge de travail soient correctement réglés ou que le réglage des performances nécessite des modifications que vous ne pouvez pas apporter à court terme en raison de processus internes ou d’autres raisons. L’ajout de ressources d’UC supplémentaires peut être utile pour ces bases de données. Vous pouvez mettre à l’échelle les ressources de base de données moyennant un temps d’arrêt minimal.

Vous pouvez ajouter des ressources de processeur à Azure SQL Database en configurant le nombre de vCores ou la configuration matérielle pour les bases de données à l’aide du modèle d’achat vCore.

Avec le cadre du modèle d’achat DTU, vous pouvez élever votre niveau de service et augmenter le nombre d’unités de transaction de base de données (DTU). Un DTU représente une mesure combinant la quantité d’UC, la mémoire, les lectures et les écritures. Un des avantages du modèle d’achat vCore est qu’il permet un contrôle plus précis du matériel en cours d’utilisation ainsi que du nombre de vCores. Vous pouvez effectuer la migration d’Azure SQL Database du modèle DTU vers le modèle vCore pour passer d’un modèle d’achat à l’autre.

Contenu connexe

En savoir plus sur l’analyse et le réglage du niveau de performance Azure SQL Database dans les articles suivants :