Résoudre les problèmes liés à une requête lente sur un pool SQL dédié

Article
04/13/2024

S’applique à : Azure Synapse Analytics

Cet article vous aide à identifier les raisons et à appliquer des atténuations pour les problèmes de performances courants liés aux requêtes sur un pool SQL dédié Azure Synapse Analytics.

Suivez les étapes pour résoudre le problème ou exécutez les étapes du notebook via Azure Data Studio. Les trois premières étapes vous guident tout au long de la collecte des données de télémétrie, qui décrivent le cycle de vie d’une requête. Les références à la fin de l’article vous aident à analyser les opportunités potentielles trouvées dans les données collectées.

Remarque

Avant de tenter d’ouvrir ce notebook, assurez-vous qu’Azure Data Studio est installé sur votre ordinateur local. Pour l’installer, accédez à Découvrir comment installer Azure Data Studio.

Ouvrir un notebook dans Azure Data Studio

Importante

La plupart des problèmes de performances signalés sont causés par :

Statistiques obsolètes
Index columnstore cluster non sains (CCI)

Pour gagner du temps de résolution des problèmes, assurez-vous que les statistiques sont créées et qu’elles sont à jour et que les cci ont été reconstruites.

Étape 1 : Identifier le request_id (également appelé QID)

Le request_id de la requête lente est requis pour rechercher les raisons potentielles d’une requête lente. Utilisez le script suivant comme point de départ pour identifier la requête que vous souhaitez résoudre. Une fois la requête lente identifiée, notez la request_id valeur.

-- Monitor active queries
SELECT *
FROM sys.dm_pdw_exec_requests
WHERE [status] NOT IN ('Completed','Failed','Cancelled')
AND session_id <> session_id()
-- AND [label] = '<YourLabel>'
-- AND resource_allocation_percentage is not NULL
ORDER BY submit_time DESC;

-- Find top 10 longest running queries
SELECT TOP 10 *
FROM sys.dm_pdw_exec_requests
ORDER BY total_elapsed_time DESC;

Pour mieux cibler les requêtes lentes, utilisez les conseils suivants lorsque vous exécutez le script :

Triez par ou submit_time DESCtotal_elapsed_time DESC pour que les requêtes les plus longues sont présentes en haut du jeu de résultats.
Utilisez OPTION(LABEL='<YourLabel>') dans vos requêtes, puis filtrez la label colonne pour les identifier.
Envisagez de filtrer tous les QID qui n’ont pas de valeur pour resource_allocation_percentage lorsque vous savez que l’instruction cible est contenue dans un lot.

Note: Soyez prudent avec ce filtre, car il peut également filtrer certaines requêtes qui sont bloquées par d’autres sessions.

Étape 2 : Déterminer où la requête prend du temps

Exécutez le script suivant pour rechercher l’étape qui peut entraîner le problème de performances de la requête. Mettez à jour les variables du script avec les valeurs décrites dans le tableau suivant. Remplacez la valeur par @ShowActiveOnly 0 pour obtenir l’image complète du plan distribué. Notez les StepIndexvaleurs , Phaseet Description de l’étape lente identifiée à partir du jeu de résultats.

Paramètre	Description
`@QID`	Valeur `request_id` obtenue à l’étape 1
`@ShowActiveOnly`	0 - Afficher toutes les étapes de la requête 1 - Afficher uniquement l’étape actuellement active

DECLARE @QID VARCHAR(16) = '<request_id>', @ShowActiveOnly BIT = 1; 
-- Retrieve session_id of QID
DECLARE @session_id VARCHAR(16) = (SELECT session_id FROM sys.dm_pdw_exec_requests WHERE request_id = @QID);
-- Blocked by Compilation or Resource Allocation (Concurrency)
SELECT @session_id AS session_id, @QID AS request_id, -1 AS [StepIndex], 'Compilation' AS [Phase],
   'Blocked waiting on '
       + MAX(CASE WHEN waiting.type = 'CompilationConcurrencyResourceType' THEN 'Compilation Concurrency'
                  WHEN waiting.type LIKE 'Shared-%' THEN ''
                  ELSE 'Resource Allocation (Concurrency)' END)
       + MAX(CASE WHEN waiting.type LIKE 'Shared-%' THEN ' for ' + REPLACE(waiting.type, 'Shared-', '')
             ELSE '' END) AS [Description],
   MAX(waiting.request_time) AS [StartTime], GETDATE() AS [EndTime],
   DATEDIFF(ms, MAX(waiting.request_time), GETDATE())/1000.0 AS [Duration],
   NULL AS [Status], NULL AS [EstimatedRowCount], NULL AS [ActualRowCount], NULL AS [TSQL]
FROM sys.dm_pdw_waits waiting
WHERE waiting.session_id = @session_id
   AND ([type] LIKE 'Shared-%' OR
      [type] in ('ConcurrencyResourceType', 'UserConcurrencyResourceType', 'CompilationConcurrencyResourceType'))
   AND [state] = 'Queued'
GROUP BY session_id 
-- Blocked by another query
UNION ALL
SELECT @session_id AS session_id, @QID AS request_id, -1 AS [StepIndex], 'Compilation' AS [Phase],
   'Blocked by ' + blocking.session_id + ':' + blocking.request_id + ' when requesting ' + waiting.type + ' on '
   + QUOTENAME(waiting.object_type) + waiting.object_name AS [Description],
   waiting.request_time AS [StartTime], GETDATE() AS [EndTime],
   DATEDIFF(ms, waiting.request_time, GETDATE())/1000.0 AS [Duration],
   NULL AS [Status], NULL AS [EstimatedRowCount], NULL AS [ActualRowCount],
   COALESCE(blocking_exec_request.command, blocking_exec_request.command2) AS [TSQL]
FROM sys.dm_pdw_waits waiting
   INNER JOIN sys.dm_pdw_waits blocking
      ON waiting.object_type = blocking.object_type
      AND waiting.object_name = blocking.object_name
   INNER JOIN sys.dm_pdw_exec_requests blocking_exec_request
      ON blocking.request_id = blocking_exec_request.request_id
WHERE waiting.session_id = @session_id AND waiting.state = 'Queued'
   AND blocking.state = 'Granted' AND waiting.type != 'Shared' 
-- Request Steps
UNION ALL
SELECT @session_id AS session_id, @QID AS request_id, step_index AS [StepIndex],
       'Execution' AS [Phase], operation_type + ' (' + location_type + ')' AS [Description],
       start_time AS [StartTime], end_time AS [EndTime],
       total_elapsed_time/1000.0 AS [Duration], [status] AS [Status],
       CASE WHEN estimated_rows > -1 THEN estimated_rows END AS [EstimatedRowCount],
       CASE WHEN row_count > -1 THEN row_count END AS [ActualRowCount],
       command AS [TSQL]
FROM sys.dm_pdw_request_steps
WHERE request_id = @QID
   AND [status] = CASE @ShowActiveOnly WHEN 1 THEN 'Running' ELSE [status] END
ORDER BY StepIndex;

Étape 3 : Examiner les détails de l’étape

Exécutez le script suivant pour passer en revue les détails de l’étape identifiée à l’étape précédente. Mettez à jour les variables du script avec les valeurs décrites dans le tableau suivant. Remplacez la valeur par @ShowActiveOnly 0 pour comparer tous les minutages de distribution. Notez la wait_type valeur de la distribution susceptible d’entraîner le problème de performances.

Paramètre	Description
`@QID`	Valeur `request_id` obtenue à l’étape 1
`@StepIndex`	Valeur `StepIndex` identifiée à l’étape 2
`@ShowActiveOnly`	0 - Afficher toutes les distributions pour la valeur donnée `StepIndex` 1 - Afficher uniquement les distributions actuellement actives pour la valeur donnée `StepIndex`

DECLARE @QID VARCHAR(16) = '<request_id>', @StepIndex INT = <StepIndex>, @ShowActiveOnly BIT = 1;
WITH dists
AS (SELECT request_id, step_index, 'sys.dm_pdw_sql_requests' AS source_dmv,
       distribution_id, pdw_node_id, spid, 'NativeSQL' AS [type], [status],
       start_time, end_time, total_elapsed_time, row_count
    FROM sys.dm_pdw_sql_requests
    WHERE request_id = @QID AND step_index = @StepIndex
    UNION ALL
    SELECT request_id, step_index, 'sys.dm_pdw_dms_workers' AS source_dmv,
       distribution_id, pdw_node_id, sql_spid AS spid, [type],
       [status], start_time, end_time, total_elapsed_time, rows_processed as row_count
    FROM sys.dm_pdw_dms_workers
    WHERE request_id = @QID AND step_index = @StepIndex
   )
SELECT sr.step_index, sr.distribution_id, sr.pdw_node_id, sr.spid,
       sr.type, sr.status, sr.start_time, sr.end_time,
       sr.total_elapsed_time, sr.row_count, owt.wait_type, owt.wait_time
FROM dists sr
   LEFT JOIN sys.dm_pdw_nodes_exec_requests owt
      ON sr.pdw_node_id = owt.pdw_node_id
         AND sr.spid = owt.session_id
         AND ((sr.source_dmv = 'sys.dm_pdw_sql_requests'
                 AND sr.status = 'Running') -- sys.dm_pdw_sql_requests status
              OR (sr.source_dmv = 'sys.dm_pdw_dms_requests'
                     AND sr.status not LIKE 'Step[CE]%')) -- sys.dm_pdw_dms_workers final statuses
WHERE sr.request_id = @QID
      AND ((sr.source_dmv = 'sys.dm_pdw_sql_requests' AND sr.status =
               CASE WHEN @ShowActiveOnly = 1 THEN 'Running' ELSE sr.status END)
           OR (sr.source_dmv = 'sys.dm_pdw_dms_workers' AND sr.status NOT LIKE
                  CASE WHEN @ShowActiveOnly = 1 THEN 'Step[CE]%' ELSE '' END))
      AND sr.step_index = @StepIndex
ORDER BY distribution_id

Étape 4 : Diagnostiquer et atténuer

Problèmes liés à la phase de compilation

Selon les valeurs obtenues à l’étapeDescription 2, case activée la section appropriée pour plus d’informations dans le tableau suivant.

Description	Cause courante
`Compilation Concurrency`	Bloqué : accès concurrentiel de compilation
`Resource Allocation (Concurrency)`	Bloqué : allocation de ressources

Si la requête est en cours d’exécution status identifiée à l’étape 1, mais qu’il n’y a pas d’informations sur l’étape 2, case activée la cause qui convient le mieux à votre scénario pour obtenir plus d’informations à partir du tableau suivant.

Scénario	Cause courante
L’instruction contient une logique de filtre de jointure complexe ou effectue des jointures dans la `WHERE` clause	Requête complexe ou syntaxe JOIN plus ancienne
L’instruction est une instruction ou `TRUNCATE TABLE` de longue durée `DROP TABLE`	DROP TABLE ou TRUNCATE TABLE de longue durée
Les cci ont un pourcentage élevé de lignes supprimées ou ouvertes (consultez Optimisation des index columnstore cluster)	Cci non saines (généralement)

Analysez le jeu de résultats à l’étape 1 pour rechercher une ou plusieurs CREATE STATISTICS instructions exécutées immédiatement après la soumission lente de la requête. Vérifiez la cause qui convient le mieux à votre scénario dans le tableau suivant.

Scénario	Cause courante
Statistiques créées de manière inattendue	Délai de création automatique des statistiques
Échec de la création des statistiques après 5 minutes	Délai d’expiration de la création automatique des statistiques

Bloqué : accès concurrentiel de compilation

Les blocs de compilation d’accès concurrentiel se produisent rarement. Toutefois, si vous rencontrez ce type de bloc, cela signifie qu’un grand volume de requêtes ont été envoyées en peu de temps et qu’elles ont été mises en file d’attente pour commencer la compilation.

Atténuations

Réduisez le nombre de requêtes envoyées simultanément.

Bloqué : allocation de ressources

Le fait d’être bloqué pour l’allocation de ressources signifie que votre requête attend de s’exécuter en fonction des points suivants :

Quantité de mémoire accordée en fonction de la classe de ressources ou de l’affectation de groupe de charge de travail associée à l’utilisateur.
Quantité de mémoire disponible sur le système ou le groupe de charge de travail.
(Facultatif) Importance du groupe/classifieur de charge de travail.

Atténuations

Attendez la fin de la session de blocage.
Évaluez le choix de classe de ressource. Pour plus d’informations, consultez Limites d’accès concurrentiel.
Évaluez s’il est préférable de tuer la session bloquante.

Requête complexe ou syntaxe JOIN plus ancienne

Vous pouvez rencontrer une situation où les méthodes de l’optimiseur de requête par défaut sont prouvées inefficaces, car la phase de compilation prend beaucoup de temps. Cela peut se produire si la requête :

Implique un nombre élevé de jointures et/ou de sous-requêtes (requête complexe).
Utilise des jointures dans la FROM clause (et non des jointures de style ANSI-92).

Bien que ces scénarios soient atypiques, vous disposez d’options pour tenter de remplacer le comportement par défaut afin de réduire le temps nécessaire à l’optimiseur de requête pour choisir un plan.

Atténuations

Utilisez des jointures de style ANSI-92.
Ajouter des indicateurs de requête : OPTION(FORCE ORDER, USE HINT ('FORCE_LEGACY_CARDINALITY_ESTIMATION')). Pour plus d’informations, consultez FORCE ORDER and Cardinality Estimation (SQL Server).
Divisez la requête en plusieurs étapes moins complexes.

DROP TABLE ou TRUNCATE TABLE de longue durée

Pour gagner en efficacité au moment de l’exécution, les instructions et TRUNCATE TABLE reportent le DROP TABLE nettoyage du stockage à un processus en arrière-plan. Toutefois, si votre charge de travail exécute un nombre élevé d’instructions dans un laps de DROP/TRUNCATE TABLE temps court, il est possible que les métadonnées soient encombrées et entraînent l’exécution lente des instructions suivantes.DROP/TRUNCATE TABLE

Atténuations

Identifiez une fenêtre de maintenance, arrêtez toutes les charges de travail et exécutez DBCC SHRINKDATABASE pour forcer un nettoyage immédiat des tables précédemment supprimées ou tronquées.

Cci non saines (généralement)

L’intégrité médiocre de l’index columnstore cluster (CCI) nécessite des métadonnées supplémentaires, ce qui peut amener l’optimiseur de requête à prendre plus de temps pour déterminer un plan optimal. Pour éviter cette situation, assurez-vous que toutes vos CCI sont en bonne santé.

Atténuations

Évaluez et corrigez l’intégrité de l’index columnstore en cluster dans un pool SQL dédié.

Délai de création automatique des statistiques

L’option AUTO_CREATE_STATISTICScréer automatiquement des statistiques permet ON par défaut de s’assurer que l’optimiseur de requête peut prendre de bonnes décisions de plan distribué. Toutefois, le processus de création automatique lui-même peut rendre une requête initiale plus longue que les exécutions ultérieures de la même requête.

Atténuations

Si la première exécution de la requête nécessite régulièrement la création de statistiques, vous devez créer manuellement des statistiques avant l’exécution de la requête.

Délai d’expiration de la création automatique des statistiques

L’option AUTO_CREATE_STATISTICScréer automatiquement des statistiques permet ON par défaut de s’assurer que l’optimiseur de requête peut prendre de bonnes décisions de plan distribué. La création automatique des statistiques se produit en réponse à une instruction SELECT et a un seuil de 5 minutes. Si la taille des données et/ou le nombre de statistiques à créer nécessitent plus de 5 minutes, la création automatique des statistiques est abandonnée afin que la requête puisse continuer l’exécution. L’échec de la création des statistiques peut avoir un impact négatif sur la capacité de l’optimiseur de requête à générer un plan d’exécution distribué efficace, ce qui entraîne des performances de requête médiocres.

Atténuations

Créez manuellement les statistiques au lieu de vous appuyer sur la fonctionnalité de création automatique pour les tables/colonnes identifiées.

Problèmes de phase d’exécution

Utilisez le tableau suivant pour analyser le jeu de résultats à l’étape 2. Déterminez votre scénario et case activée la cause courante pour obtenir des informations détaillées et les étapes d’atténuation possibles.

Scénario	Cause courante
`EstimatedRowCount` / `ActualRowCount` < 25%	Estimations inexactes
La `Description` valeur indique `BroadcastMoveOperation` et la requête fait référence à une table répliquée.	Tables répliquées non mises en cache
1. `@ShowActiveOnly` = 0 2. Un nombre élevé ou inattendu d’étapes (`step_index`) est observé. 3. Les types de données des colonnes de jointure ne sont pas identiques entre les tables.	Type/taille de données incompatibles
1. La `Description` valeur indique `HadoopBroadcastOperation`ou `HadoopRoundRobinOperationHadoopShuffleOperation`. 2. La `total_elapsed_time` valeur d’un donné `step_index` est incohérente entre les exécutions.	Requêtes de table externe ad hoc

Vérifiez la total_elapsed_time valeur obtenue à l’étape 3. S’il est considérablement plus élevé dans quelques distributions dans une étape donnée, procédez comme suit :
1. Vérifiez la distribution des données pour chaque table référencée dans le TSQL champ associé step_id en exécutant la commande suivante sur chaque table :
```
DBCC PDW_SHOWSPACEUSED(<table>);
```
2. Si <la valeur> minimale des lignes/<la valeur>> maximale des lignes est 0,1, accédez à Asymétrie des données (stockées) .
3. Sinon, accédez à Asymétrie des données en cours.

Estimations inexactes

Ayez vos statistiques à jour pour vous assurer que l’optimiseur de requête génère un plan optimal. Lorsque le nombre de lignes estimé est nettement inférieur aux nombres réels, les statistiques doivent être conservées.

Atténuations

Créer/mettre à jour des statistiques.

Tables répliquées non mises en cache

Si vous avez créé des tables répliquées et que vous ne parvenez pas à chauffer correctement le cache des tables répliquées, des performances médiocres inattendues entraînent des déplacements de données supplémentaires ou la création d’un plan distribué non optimal.

Atténuations

Réchauffez le cache répliqué après les opérations DML.
En cas d’opérations DML fréquentes, remplacez la distribution de la table par ROUND_ROBIN.

Type/taille de données incompatibles

Lors de la jointure de tables, assurez-vous que le type de données et la taille des colonnes de jointure correspondent. Sinon, cela entraîne des déplacements de données inutiles qui diminuent la disponibilité du processeur, des E/S et du trafic réseau vers le reste de la charge de travail.

Atténuations

Régénérez les tables pour corriger les colonnes de table associées qui n’ont pas de type de données et de taille identiques.

Requêtes de table externe ad hoc

Les requêtes sur des tables externes sont conçues dans le but de charger des données en bloc dans le pool SQL dédié. Les requêtes ad hoc sur des tables externes peuvent subir des durées variables en raison de facteurs externes, tels que les activités de conteneur de stockage simultanées.

Atténuations

Chargez d’abord les données dans le pool SQL dédié , puis interrogez les données chargées.

Asymétrie des données (stockées)

L’asymétrie des données signifie que les données ne sont pas distribuées uniformément entre les distributions. Chaque étape du plan distribué nécessite l’exécution de toutes les distributions avant de passer à l’étape suivante. Lorsque vos données sont asymétriques, le potentiel complet des ressources de traitement, telles que le processeur et les E/S, ne peut pas être atteint, ce qui entraîne des temps d’exécution plus lents.

Atténuations

Passez en revue nos conseils pour les tables distribuées afin de vous aider à choisir une colonne de distribution plus appropriée.

Asymétrie des données en cours d’exécution

L’asymétrie des données en cours est une variante du problème d’asymétrie des données (stockées). Toutefois, ce n’est pas la distribution des données sur le disque qui est asymétrique. La nature du plan distribué pour des filtres ou des données groupées particulières provoque une ShuffleMoveOperation opération de type. Cette opération produit une sortie asymétrique à consommer en aval.

Atténuations

Assurez-vous que les statistiques sont créées et à jour.
Modifiez l’ordre de vos GROUP BY colonnes pour qu’il y a une colonne à cardinalité plus élevée.
Créez des statistiques sur plusieurs colonnes si les jointures couvrent plusieurs colonnes.
Ajoutez un indicateur OPTION(FORCE_ORDER) de requête à votre requête.
Refactoriser la requête.

Problèmes de type d’attente

Si aucun des problèmes courants ci-dessus ne s’applique à votre requête, les données de l’étape 3 permettent de déterminer les types d’attente (dans wait_type et wait_time) qui interfèrent avec le traitement des requêtes pour l’étape la plus longue. Il existe un grand nombre de types d’attente, qui sont regroupés en catégories associées en raison d’atténuations similaires. Suivez ces étapes pour localiser la catégorie d’attente de votre étape de requête :

Identifiez dans wait_typel’étape 3 qui prend le plus de temps.
Recherchez le type d’attente dans la table de mappage des catégories d’attente et identifiez la catégorie d’attente dans laquelle il est inclus.
Développez la section relative à la catégorie d’attente dans la liste suivante pour les atténuations recommandées.

Compilation

Procédez comme suit pour atténuer les problèmes de type d’attente de la catégorie Compilation :

Régénérez des index pour tous les objets impliqués dans la requête problématique.
Mettre à jour les statistiques sur tous les objets impliqués dans la requête problématique.
Testez à nouveau la requête problématique pour vérifier si le problème persiste.

Si le problème persiste, alors :

Créez un fichier .sql avec :

SET QUERY_DIAGNOSTICS ON; <Your_SQL>; SET QUERY_DIAGNOSTICS OFF;

Ouvrez une fenêtre d’invite de commandes et exécutez la commande suivante :

sqlcmd −S <servername>.database.windows.net −d <databasename> −U <username> −G −I −i .\<sql_file_name>.sql −y0 −o .\<output_file_name>.txt

Ouvrez <output_file_name>.txt dans un éditeur de texte. Recherchez et copiez les plans d’exécution au niveau de la distribution (lignes commençant par <ShowPlanXML>) de l’étape la plus longue identifiée à l’étape 2 dans des fichiers texte distincts avec une extension .sqlplan .

Note: Chaque étape du plan distribué a généralement enregistré 60 plans d’exécution au niveau de la distribution. Assurez-vous que vous préparez et comparez les plans d’exécution à partir de la même étape de plan distribué.
La requête Étape 3 révèle souvent quelques distributions qui prennent beaucoup plus de temps que d’autres. Dans SQL Server Management Studio, comparez les plans d’exécution au niveau de la distribution (à partir des fichiers .sqlplan créés) d’une distribution de longue durée à une distribution rapide pour analyser les causes potentielles des différences.

Verrou, thread de travail

Envisagez de modifier les tables qui subissent de petites modifications fréquentes pour utiliser un index de magasin de lignes au lieu d’une cci.
Effectuez un traitement par lots de vos modifications et mettez à jour la cible avec plus de lignes sur une base moins fréquente.

E/S de mémoire tampon, autres E/S de disque, E/S de journal tran

Cci non saines

Les interfaces réseau non saines contribuent à l’augmentation des E/S, du processeur et de l’allocation de mémoire, ce qui, à son tour, a un impact négatif sur les performances des requêtes. Pour atténuer ce problème, essayez l’une des méthodes suivantes :

Évaluez et corrigez l’intégrité de l’index columnstore en cluster dans un pool SQL dédié.
Exécutez et examinez la sortie de la requête répertoriée dans Optimisation des index columnstore cluster pour obtenir une base de référence.
Suivez les étapes pour reconstruire les index afin d’améliorer la qualité des segments, en ciblant les tables impliquées dans l’exemple de requête de problème.

Statistiques obsolètes

Des statistiques obsolètes peuvent entraîner la génération d’un plan distribué non optimisé, ce qui implique plus de déplacement de données que nécessaire. Le déplacement inutile des données augmente la charge de travail non seulement sur vos données au repos, mais également sur le tempdb. Étant donné que les E/S sont une ressource partagée entre toutes les requêtes, les impacts sur les performances peuvent être ressentis par l’ensemble de la charge de travail.

Pour remédier à cette situation, assurez-vous que toutes les statistiques sont à jour et qu’un plan de maintenance est en place pour les tenir à jour pour les charges de travail utilisateur.

Charges de travail d’E/S lourdes

Votre charge de travail globale peut lire de grandes quantités de données. Les pools SQL dédiés Synapse mettez à l’échelle les ressources conformément à la DWU. Pour obtenir de meilleures performances, envisagez l’une ou l’autre des deux :

Utilisation d’une classe de ressources plus grande pour vos requêtes.
Augmentez les ressources de calcul.

PROCESSEUR, parallélisme

Scénario	Limitation des risques
Mauvaise santé de l’ICC	Évaluer et corriger l’intégrité des index columnstore en cluster dans un pool SQL dédié
Les requêtes utilisateur contiennent des transformations	Déplacer toute la mise en forme et toute autre logique de transformation dans les processus ETL afin que les versions mises en forme soient stockées
Charge de travail hiérarchisée de manière incorrecte	Implémenter l’isolation des charges de travail
DWU insuffisant pour la charge de travail	Envisager d’augmenter les ressources de calcul

E/S réseau

Si le problème se produit pendant une RETURN opération à l’étape 2,

Réduisez le nombre de processus parallèles simultanés.
Effectuez un scale-out du processus le plus impacté vers un autre client.

Pour toutes les autres opérations de déplacement de données, il est probable que les problèmes réseau semblent internes au pool SQL dédié. Pour tenter d’atténuer rapidement ce problème, procédez comme suit :

Mettre à l’échelle votre pool SQL dédié vers DW100c
Effectuer un scale-back au niveau DWU souhaité

SQL CLR

Évitez l’utilisation fréquente de la FORMAT() fonction en implémentant une autre méthode de transformation des données (par exemple, CONVERT() avec style).

Partager via

Résoudre les problèmes liés à une requête lente sur un pool SQL dédié

Étape 1 : Identifier le request_id (également appelé QID)

Étape 2 : Déterminer où la requête prend du temps

Étape 3 : Examiner les détails de l’étape

Étape 4 : Diagnostiquer et atténuer

Problèmes liés à la phase de compilation

Problèmes de phase d’exécution

Problèmes de type d’attente

Commentaires

Ressources supplémentaires