Partager via

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

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. Les trois premières étapes vous guident tout au long de la collecte de données de télémétrie, qui décrit 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.

Important

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

  • Statistiques obsolètes
  • Index columnstore non sains (CCIs)

Pour gagner du temps de résolution des problèmes, assurez-vous que les statistiques sont créées et à jour, et régénérez les index columnstore groupés dans le pool SQL dédié.

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

La request_id requête lente est nécessaire pour identifier les raisons potentielles d'une requête lente. Utilisez le script suivant comme point de départ pour identifier la requête à résoudre. Une fois la requête lente identifiée, notez la request_id valeur.

Tout d’abord, surveillez les requêtes actives. Cette requête est triée par les lignes les plus récentes en premier.

-- 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;

Ensuite, recherchez les requêtes actives qui ont le temps d’exécution le plus long, en commençant par les requêtes les plus longues en cours d’exécution.

-- 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 submit_time DESC ou total_elapsed_time DESC pour afficher les requêtes les plus longues en haut du jeu de résultats.
  • Utilisez le OPTION(LABEL='<YourLabel>') dans vos requêtes, puis filtrez la colonne label pour les identifier.
  • Envisagez de filtrer les QID qui n’ont pas de valeur pour resource_allocation_percentage lorsque vous savez que l’instruction cible est contenue dans un lot. 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 susceptible d’entraîner le problème de performances de la requête. Mettez à jour les variables dans le script avec les valeurs décrites dans le tableau suivant. Modifiez la valeur @ShowActiveOnly en 0 pour obtenir l’image complète du plan distribué. Notez les valeurs de StepIndex, Phase et Description de l'étape lente identifiée à partir du jeu de résultats.

Paramètre Description
@QID La valeur est obtenue à l’étape request_id 1.
@ShowActiveOnly Pour définir la valeur à 0, affiche toutes les étapes de la requête.
Régler la valeur sur 1 pour afficher uniquement l'étape en cours.		 
DECLARE @QID AS VARCHAR (16) = '<request_id>', @ShowActiveOnly AS BIT = 1;
-- Retrieve session_id of QID

DECLARE @session_id AS 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 AS waiting
     INNER JOIN
     sys.dm_pdw_waits AS blocking
     ON waiting.object_type = blocking.object_type
        AND waiting.object_name = blocking.object_name
     INNER JOIN
     sys.dm_pdw_exec_requests AS 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 : Passer en revue 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 dans le script avec les valeurs décrites dans le tableau suivant. Modifiez la valeur @ShowActiveOnly en 0 afin de 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 La valeur est obtenue à l’étape request_id 1.
@StepIndex La StepIndex valeur est identifiée à l’étape 2.
@ShowActiveOnly Définir la valeur pour 0 afficher toutes les distributions de la valeur donnée StepIndex .
Définir la valeur pour 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 de phase de compilation

Bloqué : concurrence lors de la compilation

Les blocs de compilation de la concurrence se produisent rarement. Toutefois, si vous rencontrez ce type de bloc, cela signifie qu’un grand nombre de requêtes ont été envoyées dans un court délai et ont été mis 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

Étant bloqué pour l’allocation de ressources, votre requête attend d’être exécutée en fonction des points suivants :

  • Quantité de mémoire accordée en fonction de l’affectation de groupe de ressources ou de groupe de charge de travail associée à l’utilisateur.
  • Quantité de mémoire disponible sur le groupe de charge de travail ou système.
  • (Facultatif) L'importance du groupe de charge de travail ou du classificateur.

Atténuations

Requête complexe ou syntaxe JOIN antérieure

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

  • Implique un grand nombre 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 avez des 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).
  • Décomposez la requête en plusieurs étapes moins complexes.
DROP TABLE ou TRUNCATE TABLE longue durée

Pour améliorer l’efficacité du temps d’exécution, les instructions DROP TABLE reportent le TRUNCATE TABLE nettoyage du stockage vers un processus en arrière-plan. Toutefois, si votre charge de travail effectue un nombre élevé d’instructions dans un délai court, il est possible que les métadonnées soient encombrées et provoque l’exécution lente des instructions suivantesDROP/TRUNCATE TABLE.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.


CCIs non-saines (généralement)

La mauvaise santé de l’index columnstore en cluster 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 de SQL dédié.


Retard de la création automatique des statistiques

L’option de création automatique de statistiques est activée par défaut pour garantir que l’optimiseur de requête puisse prendre de bonnes décisions de plan distribué. Toutefois, le processus de création automatique lui-même peut prendre plus de temps que les exécutions suivantes de la même requête.

Atténuations

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


Créer automatiquement des délais d’expiration des statistiques

L’option de création automatique de statistiques est activée ON par défaut pour garantir que l’optimiseur de requête puisse prendre de bonnes décisions de plan distribué. La création automatique de statistiques se produit en réponse à une instruction SELECT et a un seuil de 5 minutes à terminer. Si la taille des données et/ou le nombre de statistiques à créer nécessitent plus de 5 minutes, la création automatique de statistiques sera abandonnée afin que la requête puisse poursuivre l’exécution. L’échec de création des statistiques peut affecter négativement 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 vérifiez la cause courante pour obtenir des informations détaillées et les étapes d’atténuation possibles.

    Scénario Cause commune
    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 de colonnes de jointure ne sont pas identiques entre les tables.    		 Type/taille de données incompatibles
    1. La Description valeur indique HadoopBroadcastOperation, HadoopRoundRobinOperation ou HadoopShuffleOperation.
    2. La total_elapsed_time valeur d’une donnée step_index est incohérente entre les exécutions.    		 Requêtes de table externe ad hoc

  • Vérifiez la valeur obtenue à l’étape total_elapsed_time 3. S’il est beaucoup 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 chacun d’eux :

      DBCC PDW_SHOWSPACEUSED(<table>);

    2. Si <la valeur> minimale des lignes/<la valeur>> maximale des lignes est 0,1, accédez à Data skew (stocké).

    3. Sinon, accédez aux biais des données en vol.

Estimations inexactes

Disposez de 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 au nombre réel, les statistiques doivent être conservées.

Atténuations

Tout d’abord, vérifiez la précision des statistiques sur un pool SQL dédié. Si nécessaire, créez ou mettez à jour les statistiques.


Tables répliquées non mises en cache

Si vous avez créé des tables répliquées et que vous ne parvenez pas à réchauffer correctement le cache de table répliqué, des performances inattendues médiocres 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.
  • S’il existe des opérations DML fréquentes, remplacez la distribution de la table ROUND_ROBINpar .
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. Dans le cas contraire, les mouvements de données inutiles diminueront 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 et de taille de données identiques.


Requêtes de table externe ad hoc

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

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 que toutes les distributions soient terminées 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 d’aider votre choix d’une colonne de distribution plus appropriée.


Asymétrie des données en cours de vol

L’asymétrie des données en cours de vol est une variante du problème d’asymétrie des données (stocké). Mais ce n’est pas la distribution de données sur le disque qui est asymétrique. La nature du plan distribué pour des filtres particuliers ou des données groupées entraîne une opération de type ShuffleMoveOperation. Cette opération produit une sortie biaisée pour utilisation en aval.

Atténuations

  • Vérifiez que les statistiques sont créées et à jour. Vous pouvez vérifier leur précision en suivant les étapes décrites dans Vérifier la précision des statistiques sur un pool SQL dédié.
  • Modifiez l'ordre de vos GROUP BY colonnes pour commencer par une colonne possédant une cardinalité plus élevée.
  • Créez des statistiques à plusieurs colonnes si les jointures couvrent plusieurs colonnes.
  • Ajoutez un indicateur OPTION(FORCE_ORDER) de requête à votre requête.
  • Refactorisez la requête.

Problèmes liés au type d'attente

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

  1. Identifiez l’étape wait_type3 qui prend le plus de temps.
  2. Recherchez le type d’attente dans la table de mappage des catégories d’attente et identifiez la catégorie d’attente dans laquelle elle est incluse.
  3. Élargissez la section relative à la catégorie « attente » dans la liste suivante pour les mesures d’atténuation recommandées.
Compilation

Pour atténuer les problèmes liés au type d’attente de la catégorie Compilation, procédez comme suit :

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

Si le problème persiste, effectuez les actions suivantes :

  1. Créez un fichier .sql avec :

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

  2. 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

  3. 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.

    Remarque : chaque étape du plan distribué aura généralement enregistré 60 plans d’exécution au niveau de la distribution. Vérifiez que vous préparez et comparez les plans d’exécution à partir de la même étape de plan distribué.

  4. La requête Étape 3 révèle fréquemment 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 des tables qui subissent des modifications fréquentes et petites pour utiliser un index de stockage en lignes au lieu de CCI.
  • Effectuez un lot 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 du journal de transaction

Cci non saines

Les CCI insalubres contribuent à une utilisation accrue de l’I/O, du CPU et de l’allocation de mémoire, ce qui, à son tour, a un impact négatif sur les performances de la requête. Pour atténuer ce problème, essayez l’une des méthodes suivantes :

Statistiques obsolètes

Les 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 l'E/S est une ressource partagée pour l’ensemble des requêtes, l’impact sur les performances peut être ressenti par la totalité de la charge de travail.

L’optimiseur s’appuie sur des statistiques pour estimer le nombre de lignes qui seront retournées par une requête. Les statistiques permettent à l'optimiseur de requête de choisir le plan le plus efficace ou d'effectuer la meilleure opération de déplacement (par exemple, une opération de répartition ou une opération de diffusion) pour aligner les données lors de l'application de la condition de jointure. La meilleure condition de jointure dépend du type de distribution de table.

Par exemple, si le nombre réel de lignes d’une table donnée est de 60 millions et que le nombre estimé de lignes est de 1 000 (au niveau du nœud de contrôle), l’optimiseur peut choisir une opération de déplacement de type Broadcast. Ce comportement est dû au fait que le coût est perçu comme inférieur à un mouvement de redistribution, compte tenu de l'hypothèse de l'optimiseur selon laquelle la table contient uniquement 1 000 lignes. Toutefois, une fois l’exécution réelle commencée, le moteur déplace 60 millions de lignes dans le cadre de l’exécution à l’aide d’un déplacement de diffusion, ce qui peut être une opération coûteuse compte tenu de la taille des données et du nombre de lignes. Par conséquent, si la taille des données est importante, cela peut entraîner des problèmes de performances pour la requête elle-même et d’autres requêtes, ce qui entraîne une utilisation élevée du processeur.

Pour remédier à cette situation, assurez-vous que toutes les statistiques sont à jour et qu’un plan de maintenance est en place pour les maintenir à jour pour les charges de travail des utilisateurs. Vous pouvez vérifier la précision des statistiques en suivant les étapes décrites dans Vérifier la précision des statistiques sur un pool SQL dédié.

Tâches lourdes d’E/S

Dans l'ensemble, votre charge de travail pourrait consister à lire de grandes quantités de données. les pools de SQL de Synapse dédiés dimensionnent les ressources conformément aux DWU. Pour obtenir de meilleures performances, envisagez soit les deux :

PROCESSEUR, parallélisme
Scénario Limitation des risques
Mauvaise santé du CCI Évaluer et corriger l’intégrité de l’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 mal hiérarchisée Implémenter l’isolation de la charge de travail
DWU insuffisant pour la charge de travail Envisagez 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 affecté 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 :

  1. Mettez à l’échelle votre pool de SQL dédié vers DW100c
  2. Redimensionner au niveau de DWU souhaité
SQL CLR

Évitez l’utilisation fréquente de la FORMAT() fonction en implémentant une autre façon de transformer les données (par exemple, CONVERT() avec un style).


  • Last updated on