Amazon Redshift ne prendra plus en charge la création de nouveaux Python à UDFs partir du patch 198. UDFs Le Python existant continuera de fonctionner jusqu'au 30 juin 2026. Pour plus d’informations, consultez le [ billet de blog ](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/).
Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Réglage de performances des requêtes
Amazon Redshift utilise des requêtes basées sur le langage de requête structuré (SQL) pour interagir avec les données et les objets du système. Le langage de manipulation de données (Data Manipulation Language, DML) constitue le sous-ensemble de SQL que vous utilisez pour afficher, ajouter, modifier et supprimer des données. Le langage de définition de données (Data definition language, DDL) constitue le sous-ensemble de SQL que vous utilisez pour ajouter, modifier et supprimer des objets de base de données comme des tables et des vues.
Une fois votre système configuré, vous utilisez généralement le plus souvent le DML, en particulier la commande [SELECT](r_SELECT_synopsis.md) permettant de récupérer et d’afficher des données. Pour écrire des requêtes d’extraction de données efficaces dans Amazon Redshift, familiarisez-vous avec SELECT et appliquez les conseils décrits dans la section [Bonnes pratiques Amazon Redshift pour la conception de tables](c_designing-tables-best-practices.md) pour optimiser l’efficacité des requêtes.
Pour comprendre comment Amazon Redshift traite les requêtes, consultez les rubriques [Traitement des requêtes](c-query-processing.md) et [Analyse et amélioration des requêtes](c-query-tuning.md). Ensuite, vous pouvez appliquer ces informations en liaison avec des outils de diagnostic afin d’identifier et de supprimer les problèmes de performances des requêtes.
Pour identifier et résoudre certains des problèmes les plus courants et les plus graves que vous êtes susceptibles de rencontrer avec les requêtes Amazon Redshift, utilisez la section [Résolution des problèmes](queries-troubleshooting.md).
**Topics**
+ [Traitement des requêtes](c-query-processing.md)
+ [Analyse et amélioration des requêtes](c-query-tuning.md)
+ [Résolution des problèmes](queries-troubleshooting.md)
# Traitement des requêtes
Amazon Redshift achemine une requête SQL soumise à travers l’analyseur et l’optimiseur pour développer un plan de requête. Le moteur d’exécution traduit ensuite le plan de requête en code et envoie celui-ci aux nœuds de calcul à des fins d’exécution.
**Topics**
+ [Workflow d’exécution et de planification de requête](c-query-planning.md)
+ [Création et interprétation d’un plan de requêtes](c-the-query-plan.md)
+ [Révision des étapes du plan de requête](reviewing-query-plan-steps.md)
+ [Facteurs affectant la performance des requêtes](c-query-performance.md)
# Workflow d’exécution et de planification de requête
L’illustration suivante fournit présentation d’ensemble du workflow d’exécution et de planification de la requête.
![\[Flux de travail de planification et d’exécution de la requête pour un nœud principal.\]](http://docs.aws.amazon.com/fr_fr/redshift/latest/dg/images/07-QueryPlanning.png)
Le workflow de planification et d’exécution de la requête se déroule comme suit :
1. Le nœud principal reçoit la requête et analyse le SQL.
1. L’analyseur produit un arbre de requête initial qui est une représentation logique de la requête originale. Amazon Redshift saisit ensuite cette arborescence de requêtes dans l’optimiseur de requêtes.
1. L’optimiseur évalue et, si nécessaire, réécrit la requête afin d’optimiser son efficacité. Ce processus entraîne parfois la création de plusieurs requêtes connexes pour en remplacer une seule.
1. L’optimiseur génère un plan de requête (ou plusieurs, si l’étape précédente entraîné la création de plusieurs requêtes) pour que l’exécution s’effectue avec les meilleures performances. Le plan de requête spécifie les options d’exécution telles que les types de jointures, l’ordre des jointures, les options d’agrégation et les exigences de distribution des données.
Vous pouvez utiliser la commande [EXPLAIN](r_EXPLAIN.md) pour afficher le plan de requête. Le plan de requête est un outil fondamental permettant d’analyser et d’ajuster des requêtes complexes. Pour plus d’informations, consultez [Création et interprétation d’un plan de requêtes](c-the-query-plan.md).
1. Le moteur d’exécution traduit le plan de requête en *étapes*, *segments* et *flux* :
**Step (Étape)**
Chaque étape est une opération individuelle nécessaire au cours de l’exécution des requêtes. Les étapes peuvent être combinées afin d’autoriser les nœuds de calcul à effectuer une requête, créer une jointure ou une autre opération de base de données.
**Segment**
Combinaison de plusieurs étapes pouvant être effectuées par un processus unique, également la plus petite unité de compilation exécutable par une tranche de nœud de calcul. Une *tranche* est l’unité de traitement parallèle dans Amazon Redshift. Les segments d’un flux s’exécutent en parallèle.
**Flux**
Ensemble de segments à répartir entre les tranches de nœuds de calcul disponibles.
Le moteur d’exécution génère du code compilé basé sur les étapes, les segments et les flux. Le code compilé s’exécute plus vite qu’un code interprété et utilise moins de capacité de calcul. Ce code compilé est ensuite diffusé aux nœuds de calcul.
**Note**
Lors de l’évaluation de vos requêtes, vous devez toujours comparer les durées de la seconde exécution d’une requête, car la première durée d’exécution inclut la surcharge due à la compilation du code. Pour plus d’informations, consultez [Facteurs affectant la performance des requêtes](c-query-performance.md).
1. Les tranches de nœuds de calcul exécutent les segments de requête en parallèle. Dans le cadre de ce processus, Amazon Redshift tire parti d’une gestion optimisée des communications réseau, de la mémoire et des disques pour transmettre les résultats intermédiaires d’une étape du plan de requête à la suivante. Cela contribue également à accélérer l’exécution des requêtes.
Les étapes 5 et 6 s’effectuent une fois par flux. Le moteur crée les segments exécutables pour un flux et les envoie vers les nœuds de calcul. Lorsque les segments de ce flux sont terminés, le moteur génère les segments pour le prochain flux. Ainsi, le moteur peut analyser ce qui est arrivé dans le flux précédent (par exemple, si les opérations étaient basées sur le disque) pour influencer la génération de segments dans le flux suivant.
Lorsque les nœuds de calcul sont terminés, ils renvoient les résultats de la requête au nœud principal pour le traitement final. Le nœud principal fusionne les données en un seul jeu de résultats et traite tous les tris ou agrégations nécessaires. Le nœud principal renvoie ensuite les résultats au client.
**Note**
Au besoin, les nœuds de calcul peuvent renvoyer des données au nœud principal au cours de l’exécution des requêtes. Par exemple, si vous avez une sous-requête comportant une clause LIMIT, la limite est appliquée au nœud principal avant que les données soient redistribuées dans le cluster en vue d’un traitement ultérieur.
# Création et interprétation d’un plan de requêtes
Vous pouvez utiliser le plan de requête pour obtenir des informations sur les opérations individuelles requises pour exécuter une requête. Avant de travailler avec un plan de requête, nous vous recommandons de comprendre d’abord comment Amazon Redshift gère le traitement des requêtes et la création des plans de requête. Pour plus d’informations, consultez [Workflow d’exécution et de planification de requête](c-query-planning.md).
Pour créer un plan de requête, exécutez la commande [EXPLAIN](r_EXPLAIN.md) suivie du texte de la requête réelle. Le plan de requête vous fournit les informations suivantes :
+ Les opérations effectuées par le moteur d’exécution, en lisant les résultats de bas en haut.
+ Le type d’étape effectué par chaque opération.
+ Les tables et les colonnes utilisées dans chaque opération.
+ La quantité de données traitée dans chaque opération, en termes de nombre de lignes et de largeur de données en octets.
+ Le coût relatif de l’opération. *Cost* est une mesure qui compare les durées d’exécution relatives des étapes au sein d’un plan. Cost ne fournit pas d’informations précises sur les durées d’exécution ou la consommation de mémoire réelle, ni de comparaison significative des plans d’exécution. Il vous donne une indication des opérations d’une requête qui consomment le plus de ressources.
La commande EXPLAIN n’exécute pas réellement la requête. Elle montre seulement le plan que Amazon Redshift exécutera si la requête est exécutée dans les conditions d’utilisation actuelles. Si vous modifiez le schéma ou les données d’une table et que vous exécutez [ANALYSE](r_ANALYZE.md) à nouveau pour mettre à jour les métadonnées statistiques, le plan de requête peut être différent.
La sortie du plan de requête par EXPLAIN est une vue simplifiée et d’ensemble de l’exécution des requêtes. Il n’illustre pas les détails du traitement de requête parallèle. Pour consulter des informations détaillées, vous devez exécuter la requête elle-même, puis obtenir des informations récapitulatives sur la requête dans la vue SVL\$1QUERY\$1SUMMARY ou SVL\$1QUERY\$1REPORT. Pour plus d’informations sur l’utilisation de ces vues, consultez [Analyse du résumé de la requête](c-analyzing-the-query-summary.md).
L’exemple suivant illustre la sortie EXPLAIN pour une requête GROUP BY simple sur la table EVENT :
```
explain select eventname, count(*) from event group by eventname;
QUERY PLAN
-------------------------------------------------------------------
XN HashAggregate (cost=131.97..133.41 rows=576 width=17)
-> XN Seq Scan on event (cost=0.00..87.98 rows=8798 width=17)
```
EXPLAIN renvoie les métriques suivantes pour chaque opération :
**Cost**
Valeur relative utile pour comparer les opérations au sein d’un plan. Cost se compose de deux valeurs décimales séparées par des deux points, par exemple `cost=131.97..133.41`. La première valeur, dans le cas présent 131.97, fournit le coût relatif du renvoi de la première ligne pour cette opération. La seconde valeur, dans le cas présent 133.41, fournit le coût relatif de l’exécution de l’opération. Les coûts du plan de requête sont cumulatifs au fur et à mesure que vous lisez le plan. Le HashAggregate coût de cet exemple (131.97.. 133.41) inclut le coût du Seq Scan situé en dessous (0,00.. 87,98).
**Lignes**
Estimation du nombre de lignes à renvoyer. Dans cet exemple, l’analyse devrait renvoyer 8 798 lignes. L' HashAggregate opérateur lui-même est censé renvoyer 576 lignes (une fois que les noms d'événements dupliqués ont été supprimés du jeu de résultats).
L’estimation de lignes repose sur les statistiques disponibles générées par la commande ANALYZE. Si ANALYZE n’a pas été exécutée récemment, l’estimation sera moins fiable.
**Width**
Largeur estimée de la ligne moyenne, en octets. Dans cet exemple, la ligne moyenne devrait avoir une largeur de 17 octets.
## Opérateurs EXPLAIN
Cette section décrit brièvement les opérateurs que vous voyez le plus souvent dans la sortie EXPLAIN. Pour obtenir une liste complète des opérateurs, consultez [EXPLAIN](r_EXPLAIN.md) dans la section Commandes SQL.
### Opérateur d’analyse séquentielle
L’opérateur d’analyse séquentiel (Seq Scan) indique une analyse de table. Seq Scan analyse chaque colonne de la tableau de manière séquentielle du début à la fin et évalue les contraintes de requête (dans la clause WHERE) de chaque ligne.
### Opérateurs de jointure
Amazon Redshift sélectionne les opérateurs de jointure en fonction de la conception physique des tables jointes, de l’emplacement des données requises pour la jointure et des exigences spécifiques à la requête elle-même.
+ **Boucle imbriquée**
La jointure la moins optimale, une boucle imbriquée, est utilisée principalement pour les jointures croisées (produits cartésiens) et certaines jointures d’inégalité.
+ **Hash Join and Hash**
Généralement plus rapide qu’une boucle imbriquée, une jointure par hachage et un hachage sont utilisés pour les jointures internes et les jointures externes gauche et droite. Ces opérateurs sont utilisés lors de la jonction de tables, lorsque les colonnes de jointure ne sont pas des clés de distribution *et* des clés de tri. L’opérateur de hachage crée la table de hachage pour la table interne de la jointure ; l’opérateur de jointure par hachage lit la table externe, hache la colonne de jointure et recherche des correspondances dans la table de hachage interne.
+ **Joindre par fusion**
Généralement la jointure la plus rapide, une jointure par fusion est utilisée pour les jointures internes et externes. La jointure par fusion n’est pas utilisée pour les jointures complètes. Cet opérateur est utilisé lors de la jonction de tables lorsque les colonnes de jointure sont des clés de distribution *et* des clés de tri, et lorsque moins de 20 % des tables jointes sont non triées. Il lit les deux tables triées dans l’ordre et recherche les lignes correspondantes. Pour afficher le pourcentage de lignes non triées, interrogez la table système [SVV\$1TABLE\$1INFO](r_SVV_TABLE_INFO.md).
+ **Jointure spatiale**
Il s’agit généralement d’une jointure rapide basée sur la proximité des données spatiales, utilisées pour les types de données `GEOMETRY` et `GEOGRAPHY`.
### Opérateurs d’agrégation
Le plan de requête utilise les opérateurs suivants dans les requêtes impliquant des fonctions d’agrégation et des opérations GROUP BY.
+ **Regrouper**
Opérateur de fonctions d’agrégation scalaires telles que AVG et SUM.
+ **HashAggregate**
Opérateur des fonctions d’agrégation groupées non triées.
+ **GroupAggregate**
Opérateur des fonctions d’agrégation groupées triées.
### Opérateurs de tri
Le plan de requête utilise les opérateurs suivants lorsque les requêtes doivent trier ou fusionner des jeux de résultats.
+ **Tri**
Evalue la clause ORDER BY et d’autres opérations de tri, telles que les tris requis par les requêtes UNION et les requêtes SELECT DISTINCT de jointure et les fonctions de fenêtrage.
+ **Fusionner**
Produit des résultats triés finaux selon les résultats triés intermédiaires qui proviennent d’opérations parallèles.
### Opérateurs UNION, INTERSECT et EXCEPT
Le plan de requête utilise les opérateurs suivants pour des requêtes impliquant des opérations de jeu avec UNION, INTERSECT et EXCEPT.
+ **Subquery**
Utilisé pour exécuter des requêtes UNION.
+ **Hash Intersect Distinct **
Utilisé pour exécuter les requêtes INTERSECT .
+ **SetOp Sauf**
Utilisé pour exécuter des requêtes EXCEPT (ou MINUS).
### Autres opérateurs
Les opérateurs suivants apparaissent également fréquemment dans la sortie EXPLAIN pour les requêtes courantes.
+ **Unique**
Supprime les doublons des requêtes SELECT DISTINCT et UNION.
+ **Limite**
Traite la clause LIMIT.
+ **Fenêtre**
Exécute les fonctions de fenêtrage.
+ **Result**
Exécute les fonctions scalaires qui n’impliquent pas un accès aux tables.
+ **Subplan**
Utilisé pour certaines sous-requêtes.
+ **Réseau**
Envoie des résultats intermédiaires au nœud principal en vue d’un traitement ultérieur.
+ **Materialize**
Enregistre les lignes pour l’entrée des jointures de boucles imbriquées et quelques autres jointures de fusion.
## Jointures dans EXPLAIN
L’optimiseur de requête utilise différents types de jointures pour récupérer les données de la table, en fonction de la structure de la requête et des tables sous-jacentes. La sortie EXPLAIN fait référence au type de jointure, aux tables utilisées et à la manière dont les données de la table sont distribuées dans le cluster afin de décrire le traitement de la requête.
### Exemples de types de jointures
Les exemples suivants illustrent les différents types de jointures que l’optimiseur de requête peut utiliser. Le type de jointure utilisé dans le plan de requête dépend de la conception physique des tables impliquées.
#### Exemple : Joindre par hachage deux tables
La requête suivante joint EVENT et CATEGORY sur la colonne CATID. CATID est la clé de tri et de distribution pour CATEGORY, mais pas pour EVENT. Une jointure par hachage est effectuée avec EVENT en tant que table externe et avec CATEGORY en tant que table interne. Etant donné que CATEGORY est la table la plus petite, le planificateur en diffuse une copie aux nœuds de calcul au cours du traitement de la requête à l’aide de DS\$1BCAST\$1INNER. Le coût de la jointure de cet exemple représente la majeure partie du coût cumulé du plan.
```
explain select * from category, event where category.catid=event.catid;
QUERY PLAN
-------------------------------------------------------------------------
XN Hash Join DS_BCAST_INNER (cost=0.14..6600286.07 rows=8798 width=84)
Hash Cond: ("outer".catid = "inner".catid)
-> XN Seq Scan on event (cost=0.00..87.98 rows=8798 width=35)
-> XN Hash (cost=0.11..0.11 rows=11 width=49)
-> XN Seq Scan on category (cost=0.00..0.11 rows=11 width=49)
```
**Note**
Les retraits alignés pour les opérateurs dans la sortie EXPLAIN indiquent parfois que ces opérations ne dépendent pas l’une de l’autre et peuvent démarrer en parallèle. Dans l’exemple précédent, bien que l’analyse de la table EVENT et l’opération de hachage soient alignées, l’analyse EVENT doit attendre que l’opération de hachage soit entièrement terminée.
#### Exemple : Joindre par fusion deux tables
La requête suivante utilise également SELECT \$1, mais elle joint SALES et LISTING sur la colonne LISTID, dans laquelle LISTID a été défini comme clé de tri et de distribution des deux tables. Une jointure par fusion est choisie et aucun redistribution des données n’est requise pour la jointure (DS\$1DIST\$1NONE).
```
explain select * from sales, listing where sales.listid = listing.listid;
QUERY PLAN
-----------------------------------------------------------------------------
XN Merge Join DS_DIST_NONE (cost=0.00..6285.93 rows=172456 width=97)
Merge Cond: ("outer".listid = "inner".listid)
-> XN Seq Scan on listing (cost=0.00..1924.97 rows=192497 width=44)
-> XN Seq Scan on sales (cost=0.00..1724.56 rows=172456 width=53)
```
L’exemple suivant illustre les différents types de jointures au sein de la même requête. Comme dans l’exemple précédent, SALES et LISTING sont jointes par fusion, mais la troisième table, EVENT, doit être jointe par hachage aux résultats de la jointure par fusion. Une fois encore, la jointure par hachage implique un coût de diffusion.
```
explain select * from sales, listing, event
where sales.listid = listing.listid and sales.eventid = event.eventid;
QUERY PLAN
----------------------------------------------------------------------------
XN Hash Join DS_BCAST_INNER (cost=109.98..3871130276.17 rows=172456 width=132)
Hash Cond: ("outer".eventid = "inner".eventid)
-> XN Merge Join DS_DIST_NONE (cost=0.00..6285.93 rows=172456 width=97)
Merge Cond: ("outer".listid = "inner".listid)
-> XN Seq Scan on listing (cost=0.00..1924.97 rows=192497 width=44)
-> XN Seq Scan on sales (cost=0.00..1724.56 rows=172456 width=53)
-> XN Hash (cost=87.98..87.98 rows=8798 width=35)
-> XN Seq Scan on event (cost=0.00..87.98 rows=8798 width=35)
```
#### Exemple : Joindre, regrouper et trier
La requête suivante exécute une jointure par hachage des tables SALES et EVENT, suivie d’opérations d’agrégation et de tri afin de tenir compte de la fonction SUM groupée et de la clause ORDER BY. L’opérateur Sort initial s’exécute en parallèle sur les nœuds de calcul. Puis, l’opérateur Network envoie les résultats au nœud principal, dans lequel l’opérateur Merge produit les résultats triés finaux.
```
explain select eventname, sum(pricepaid) from sales, event
where sales.eventid=event.eventid group by eventname
order by 2 desc;
QUERY PLAN
---------------------------------------------------------------------------------
XN Merge (cost=1002815366604.92..1002815366606.36 rows=576 width=27)
Merge Key: sum(sales.pricepaid)
-> XN Network (cost=1002815366604.92..1002815366606.36 rows=576 width=27)
Send to leader
-> XN Sort (cost=1002815366604.92..1002815366606.36 rows=576 width=27)
Sort Key: sum(sales.pricepaid)
-> XN HashAggregate (cost=2815366577.07..2815366578.51 rows=576 width=27)
-> XN Hash Join DS_BCAST_INNER (cost=109.98..2815365714.80 rows=172456 width=27)
Hash Cond: ("outer".eventid = "inner".eventid)
-> XN Seq Scan on sales (cost=0.00..1724.56 rows=172456 width=14)
-> XN Hash (cost=87.98..87.98 rows=8798 width=21)
-> XN Seq Scan on event (cost=0.00..87.98 rows=8798 width=21)
```
### Redistribution des données
La sortie EXPLAIN des jointures spécifie également une méthode permettant de déplacer les données autour d’un cluster pour faciliter la jointure. Ce mouvement des données peut être une diffusion ou une redistribution. Dans une diffusion, les valeurs de données d’un côté d’une jointure sont copiées à partir de chaque nœud de calcul dans tous les autres nœuds de calcul, afin que chaque nœud de calcul se retrouve avec une copie complète des données. Dans une redistribution, les valeurs de données participantes sont envoyés de leur tranche actuelle vers une nouvelle tranche (éventuellement sur un autre nœud). Les données sont généralement redistribuées pour correspondre à la clé de distribution de l’autre table participant à la jointure si cette clé de distribution est l’une des colonnes de jointure. Si aucune des tables ne dispose de clés de distribution sur l’une des tables de jointure, les deux tables sont distribuées ou la table interne est diffusée à chaque nœud.
La sortie EXPLAIN fait également référence aux tables internes et externes. La table interne est analysée d’abord et s’affiche près de bas du plan de requête. La table interne est la table qui fait l’objet d’une recherche de correspondances. Elle est généralement conservée en mémoire, est généralement la table source pour le hachage et, si possible, est la plus petite des deux tables qui sont jointes. La table externe est la source des lignes à mettre en correspondant avec la table interne. Elle est généralement lue à partir du disque. L’optimiseur de requête choisit la table interne et la table externe en fonction des statistiques de la base de données obtenues lors de la dernière exécution de la commande ANALYZE. L’ordre des tables dans la clause FROM d’une requête ne détermine pas quelle table est interne et quelle table est externe.
Utilisez les attributs suivants dans les plans de requête pour identifier la manière dont les données sont déplacées afin de simplifier une requête :
+ **DS\$1BCAST\$1INNER**
Une copie de la totalité de la table interne est diffusée à tous les nœuds de calcul.
+ **DS\$1DIST\$1ALL\$1NONE**
Aucun redistribution n’est obligatoire, car la table interne a déjà été distribuée à chaque nœud à l’aide de DISTSTYLE ALL.
+ **DS\$1DIST\$1NONE**
Aucune table n’est redistribuée. Les jointures colocalisées sont possibles, car les tranches correspondantes sont jointes sans transfert de données entre les nœuds.
+ **DS\$1DIST\$1INNER**
La table interne est redistribuée.
+ **DS\$1DIST\$1OUTER**
La table externe est redistribuée.
+ **DS\$1DIST\$1ALL\$1INNER**
La totalité de la table interne est redistribué à une seule tranche, car la table externe utilise DISTSTYLE ALL.
+ **DS\$1DIST\$1BOTH**
Les deux tables sont redistribuées.
# Révision des étapes du plan de requête
Vous pouvez voir les étapes dans un plan de requête en exécutant la commande EXPLAIN. L’exemple suivant présente une requête SQL et commente la sortie. En lisant le plan de requête en partant du bas, vous pouvez voir chacune des opérations logiques utilisées pour exécuter la requête. Pour plus d’informations, consultez [Création et interprétation d’un plan de requêtes](c-the-query-plan.md).
```
explain
select eventname, sum(pricepaid) from sales, event
where sales.eventid = event.eventid
group by eventname
order by 2 desc;
```
```
XN Merge (cost=1002815366604.92..1002815366606.36 rows=576 width=27)
Merge Key: sum(sales.pricepaid)
-> XN Network (cost=1002815366604.92..1002815366606.36 rows=576 width=27)
Send to leader
-> XN Sort (cost=1002815366604.92..1002815366606.36 rows=576 width=27)
Sort Key: sum(sales.pricepaid)
-> XN HashAggregate (cost=2815366577.07..2815366578.51 rows=576 width=27)
-> XN Hash Join DS_BCAST_INNER (cost=109.98..2815365714.80 rows=172456 width=27)
Hash Cond: ("outer".eventid = "inner".eventid)
-> XN Seq Scan on sales (cost=0.00..1724.56 rows=172456 width=14)
-> XN Hash (cost=87.98..87.98 rows=8798 width=21)
-> XN Seq Scan on event (cost=0.00..87.98 rows=8798 width=21)
```
Dans le cadre de la génération d’un plan de requête, l’optimiseur de requêtes décompose le plan en flux, segments et étapes. L’optimiseur de requêtes décompose le plan pour préparer la distribution des données et de la charge de travail de requête entre les nœuds de calcul. Pour plus d’informations sur les flux, les segments et les étapes, consultez [Workflow d’exécution et de planification de requête](c-query-planning.md).
L’illustration suivante présente la requête précédente et le plan de requête associé. Il affiche la manière dont les opérations de requête impliquées sont mappées en étapes utilisées par Amazon Redshift pour générer du code compilé pour les tranches de nœud de calcul. Chaque opération de plan de requête correspond à plusieurs étapes dans les segments et parfois à plusieurs segments dans les flux.
![\[Une requête et son plan de requêtes associé sont mappés à trois flux.\]](http://docs.aws.amazon.com/fr_fr/redshift/latest/dg/images/map-plan-to-streams.png)
Dans cette illustration, l’optimiseur de requêtes exécute le plan de requête comme suit :
1. Dans `Stream 0`, la requête exécute `Segment 0` avec une opération d’analyse séquentielle pour analyser la table `events`. La requête passe à `Segment 1` avec une opération de hachage pour créer la table de hachage pour la table interne dans la jointure.
1. Dans `Stream 1`, la requête exécute `Segment 2` avec une opération d’analyse séquentielle pour analyser la table `sales`. Elle continue avec `Segment 2` et une jointure de hachage pour joindre des tables où les colonnes de jointure ne sont pas à la fois des clés de distribution et des clés de tri. Elle continue encore avec `Segment 2` et un agrégat de hachage pour agréger les résultats. Ensuite, la requête exécute `Segment 3` avec une opération d’agrégation de hachage pour effectuer des fonctions d’agrégat groupées non triées, ainsi qu’une opération de tri pour évaluer la clause ORDER BY et d’autres opérations de tri.
1. Dans `Stream 2`, la requête exécute une opération de réseau dans `Segment 4` et `Segment 5` pour envoyer des résultats intermédiaires au nœud principal pour un traitement ultérieur.
Le dernier segment d’une requête renvoie les données. Si le jeu de retour est agrégé ou trié, les nœuds de calcul envoient chacun leur morceau du résultat intermédiaire au nœud principal. Le nœud principal fusionne ensuite les données afin que le résultat final puisse être renvoyé au client demandeur.
Pour plus d’informations sur les opérateurs EXPLAID, consultez [EXPLAIN](r_EXPLAIN.md).
# Facteurs affectant la performance des requêtes
Un certain nombre de facteurs peut affecter les performances des requêtes. Les aspects suivants de vos opérations de données, de cluster et de base de données jouent tous un rôle dans la vitesse de traitement de vos requêtes.
+ **Nombre de nœuds, de processeurs ou de tranches** – Un nœud de calcul est partitionné en tranches. Davantage de nœuds signifie davantage de processeurs et de tranches, ce qui accélère le traitement de vos requêtes grâce à l’exécution simultanée de parties de la requête entre les tranches. Cependant, davantage de nœuds signifie également une dépense supérieure, autrement dit, il vous faudra trouver un équilibre entre les coûts et les performances en fonction de votre système. Pour plus d’informations sur l’architecture de cluster Amazon Redshift, consultez [Architecture système de l’entrepôt des données](c_high_level_system_architecture.md).
+ **Types de nœuds** : un cluster Amazon Redshift peut utiliser l’un des nombreux types de nœuds. Chaque type de nœud propose différentes tailles et limites vous permettant de mettre à l’échelle votre cluster de façon appropriée. La taille de nœud détermine la capacité de stockage, la mémoire, le processeur et le prix de chaque nœud du cluster. Pour plus d’informations sur les types de nœuds, consultez [Présentation des clusters Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html#working-with-clusters-overview) dans le *Guide de gestion Amazon Redshift*.
+ **Distribution des données** – Amazon Redshift stocke les données de la table sur les nœuds de calcul en fonction du style de distribution de la table. Lorsque vous exécutez une requête, l’optimiseur de requête redistribue les données sur les nœuds de calcul en fonction des besoins afin d’effectuer des jointures et des agrégations. Le choix du style de distribution adapté à une table permet de réduire l’impact de l’étape de la redistribution en plaçant les données à l’emplacement souhaité avant que les jointures soient effectuées. Pour plus d’informations, consultez [Distribution de données pour l’optimisation des requêtes](t_Distributing_data.md).
+ **Ordre de tri des données** – Amazon Redshift stocke les données de la table sur le disque dans un ordre trié selon les clés de tri de la table. L’optimiseur de requête et le processeur de requêtes utilisent les informations sur l’emplacement des données afin de réduire le nombre de blocs à analyser, ce qui améliore ainsi la vitesse de la requête. Pour plus d’informations, consultez [Clés de tri](t_Sorting_data.md).
+ **Taille du jeu de données** – Un volume de données plus élevé dans le cluster peut ralentir les performances des requêtes, car davantage de lignes doivent être analysées et redistribuées. Vous pouvez atténuer cet effet en nettoyant et en archivant régulièrement les données et en utilisant un prédicat afin de limiter le jeu de données de la requête.
+ **Opérations simultanées** – L’exécution de plusieurs opérations simultanément peut affecter les performances des requêtes. Chaque opération prend un ou plusieurs emplacements dans une file d’attente de requête disponible et utilise la mémoire qui leur est associée. Si d’autres opérations sont en cours d’exécution, il se peut que les emplacements de file d’attente de requête nécessaires ne soient pas disponibles. Dans ce cas, la requête devra attendre que des emplacements s’ouvrent pour commencer le traitement. Pour plus d’informations sur la création et la configuration des files d’attente de requête, consultez [Gestion de la charge de travail](cm-c-implementing-workload-management.md).
+ **Structure de requête** – La façon dont votre requête est rédigée influe sur ses performances. Écrivez autant que possible des requêtes à traiter et renvoyez aussi peu de données que nécessaire. Pour de plus amples informations, veuillez consulter [Bonnes pratiques Amazon Redshift pour la conception de requêtes](c_designing-queries-best-practices.md).
+ **Compilation de code** — Amazon Redshift génère et compile du code optimisé pour chaque plan d'exécution des requêtes. Le code compilé s'exécute plus rapidement car il élimine la surcharge liée à l'utilisation d'un interpréteur. Afin de minimiser le temps de latence pour les nouvelles requêtes tout en préservant les avantages en termes de performances du code compilé, Amazon Redshift utilise une technique appelée composition. La composition génère un arrangement léger de logiques préexistantes pour traiter les nouvelles requêtes immédiatement, tout en compilant simultanément du code hautement optimisé et spécifique aux requêtes en arrière-plan. Cela permet de supprimer la compilation du chemin critique de l'exécution des requêtes, de sorte que les nouvelles requêtes démarrent plus rapidement et offrent des performances cohérentes avec les exécutions suivantes.
Amazon Redshift utilise également un service de compilation sans serveur pour étendre les compilations de requêtes au-delà des ressources de calcul d'un cluster Amazon Redshift. Les segments de code compilés sont mis en cache à la fois localement sur le cluster et dans un cache distant pratiquement illimité qui persiste après le redémarrage du cluster. Les exécutions ultérieures de la même requête sont plus rapides car elles peuvent éviter la phase de compilation. À l'aide d'un service de compilation évolutif, Amazon Redshift compile le code en parallèle pour fournir des performances rapides et constantes.
# Analyse et amélioration des requêtes
La récupération d’informations à partir d’un entrepôt des données Amazon Redshift implique l’exécution de requêtes complexes sur des quantités de données extrêmement importantes, ce qui peut prendre beaucoup de temps à traiter. Pour être sûr de traiter les requêtes le plus rapidement possible, il existe un certain nombre d’outils que vous pouvez utiliser pour identifier les problèmes de performances potentiels.
**Topics**
+ [Flux de travail d’analyse des requêtes](c-query-analysis-process.md)
+ [Révision des alertes de requêtes](c-reviewing-query-alerts.md)
+ [Analyse du plan de requête](c-analyzing-the-query-plan.md)
+ [Analyse du résumé de la requête](c-analyzing-the-query-summary.md)
+ [Amélioration des performances des requêtes](query-performance-improvement-opportunities.md)
+ [Requêtes de diagnostics pour l’ajustement des requêtes](diagnostic-queries-for-query-tuning.md)
# Flux de travail d’analyse des requêtes
Si une requête est plus longue à traiter que prévu, utilisez les étapes suivantes pour identifier et corriger les problèmes susceptibles d’affecter négativement les performances de la requête. Si vous ne savez pas quelles requêtes de votre système peuvent voir leurs performances ajustées, commencez par exécuter la requête diagnostique dans [Identification des requêtes particulièrement indiquées pour un ajustement](identify-queries-that-are-top-candidates-for-tuning.md).
1. Assurez-vous que vos tables sont conçues conformément aux bonnes pratiques. Pour plus d’informations, consultez [Bonnes pratiques Amazon Redshift pour la conception de tables](c_designing-tables-best-practices.md).
1. Vérifiez si vous pouvez supprimer ou archiver des données superflues dans vos tables. Par exemple, supposons que vos requêtes ciblent toujours les six derniers mois de données, mais que vous avez les 18 derniers mois dans vos tables. Dans ce cas, vous pouvez supprimer ou archiver les données plus anciennes afin de réduire le nombre d’enregistrements devant être analysés et distribués.
1. Exécutez la commande [VACUUM](r_VACUUM_command.md) sur les tables de la requête pour récupérer de l’espace et trier à nouveau les lignes. L’exécution de VACUUM est utile si la région non triée est volumineuse et que la requête utilise la clé de tri dans une jointure ou dans le prédicat.
1. Exécutez la commande [ANALYSE](r_ANALYZE.md) sur les tables de la requête pour vous assurer que les statistiques sont à jour. L’exécution de ANALYZE est utile si l’une des tables de la requête a considérablement changé de taille récemment. Si l’exécution d’une commande ANALYZE complète prend trop de temps, exécutez ANALYZE sur une seule colonne pour réduire le temps de traitement. Cette approche mettra toujours à jour les statistiques de taille de la table, laquelle taille est un facteur important dans la planification de la requête.
1. Assurez-vous que votre requête a été exécutée une fois pour chaque type de client (en fonction du type de protocole de connexion utilisé par le client), afin que la requête soit mise à jour et en cache. Cette approche accélère les exécutions suivantes de la requête. Pour plus d’informations, consultez [Facteurs affectant la performance des requêtes](c-query-performance.md).
1. Vérifiez la table [STL\$1ALERT\$1EVENT\$1LOG](r_STL_ALERT_EVENT_LOG.md) afin d’identifier et de corriger les éventuels problèmes avec votre requête. Pour plus d’informations, consultez [Révision des alertes de requêtes](c-reviewing-query-alerts.md).
1. Exécutez la commande [EXPLAIN](r_EXPLAIN.md) pour obtenir le plan de requête et l’utiliser afin d’optimiser la requête. Pour plus d’informations, consultez [Analyse du plan de requête](c-analyzing-the-query-plan.md).
1. Utilisez les vues [SVL\$1QUERY\$1SUMMARY](r_SVL_QUERY_SUMMARY.md) et [SVL\$1QUERY\$1REPORT](r_SVL_QUERY_REPORT.md) pour obtenir des informations récapitulatives et les utiliser afin d’optimiser la requête. Pour plus d’informations, consultez [Analyse du résumé de la requête](c-analyzing-the-query-summary.md).
Parfois, une requête devant s’exécuter rapidement est contrainte d’attendre qu’une autre requête plus longue à s’exécuter se termine. Dans ce cas, vous pouvez ne rien avoir à améliorer dans la requête elle-même, mais vous pouvez améliorer les performances globales du système en créant et en utilisant des files d’attente de requête adaptées à chaque type de requête. Pour connaître les temps d’attente des files d’attente pour vos requêtes, consultez [Vérification des temps d’attente des requêtes dans les files d’attente](review-queue-wait-times-for-queries.md). Pour plus d’informations sur la configuration des files d’attente de requête, consultez [Gestion de la charge de travail](cm-c-implementing-workload-management.md).
# Révision des alertes de requêtes
Pour utiliser la table système [STL\$1ALERT\$1EVENT\$1LOG](r_STL_ALERT_EVENT_LOG.md) afin d’identifier et de corriger d’éventuels problèmes de performances avec votre requête, procédez comme suit :
1. Exécutez la commande suivante pour déterminer l’ID de votre requête :
```
select query, elapsed, substring
from svl_qlog
order by query
desc limit 5;
```
Examinez le texte de la requête tronquée dans le champ `substring` pour déterminer quelle valeur de `query` sélectionner. Si vous avez exécuté la requête plusieurs fois, utilisez la valeur de `query` de la ligne avec la valeur de `elapsed` inférieure. Il s’agit de la ligne de la version compilée. Si vous avez exécuté un grand nombre de requêtes, vous pouvez augmenter la valeur utilisée par la clause LIMIT utilisée pour vous assurer que votre requête est incluse.
1. Sélectionnez des lignes dans STL\$1ALERT\$1EVENT\$1LOG pour votre requête :
```
Select * from stl_alert_event_log where query = MyQueryID;
```
![\[Un exemple de résultat de la requête STL_ALERT_EVENT_LOG.\]](http://docs.aws.amazon.com/fr_fr/redshift/latest/dg/images/stl_alert_event_log_results.png)
1. Evaluez les résultats de votre requête. Utilisez le tableau suivant pour rechercher des solutions possibles aux problèmes que vous avez identifiés.
**Note**
Toutes les requêtes ne contiennent pas des lignes dans STL\$1ALERT\$1EVENT\$1LOG, seules celles ayant des problèmes identifiés.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/redshift/latest/dg/c-reviewing-query-alerts.html)
# Analyse du plan de requête
Exécutez la commande [EXPLAIN](r_EXPLAIN.md) pour obtenir un plan de requête.
Avant d’analyser le plan de requête, vous devez savoir comment le lire. Si vous ne savez pas lire un plan de requête, nous vous recommandons de lire [Création et interprétation d’un plan de requêtes](c-the-query-plan.md) avant de poursuivre.
Pour analyser les données fournies par le plan de requête, procédez comme suit :
1. Identifiez les étapes ayant le coût le plus élevé. Consacrez-vous à les optimiser lorsque vous effectuez les dernières étapes.
1. Observez les types de jointure :
+ **Boucle imbriquée** : ces jointures se produisent généralement parce qu’une condition de jointure a été omise. Pour connaître les solutions recommandées, consultez [Boucle imbriquée](query-performance-improvement-opportunities.md#nested-loop).
+ **Hachage et Joindre par hachage** : les jointures par hachage sont utilisées pour joindre des tables dans lesquelles les colonnes de jointure ne sont pas des clés de distribution, ni des clés de tri. Pour connaître les solutions recommandées, consultez [Joindre par hachage](query-performance-improvement-opportunities.md#hash-join).
+ **Joindre par fusion** : aucune modification n’est nécessaire.
1. Notez quelle table est utilisée pour la jointure interne et quelle table est utilisée pour la jointure externe. Le moteur de requête choisit généralement la plus petite table pour la jointure interne et la plus grande table pour la jointure externe. Si ce choix ne se fait pas, vos statistiques ne sont vraisemblablement pas à jour. Pour connaître les solutions recommandées, consultez [Statistiques de table manquantes ou obsolètes](query-performance-improvement-opportunities.md#table-statistics-missing-or-out-of-date).
1. Vérifiez s’il existe des opérations de tri onéreuses. Si c’est le cas, consultez [Lignes non triées ou mal triées](query-performance-improvement-opportunities.md#unsorted-or-mis-sorted-rows) pour connaître les solutions recommandées.
1. Recherchez les opérateurs de diffusion suivants là où il y a des opérations onéreuses :
+ **DS\$1BCAST\$1INNER** : indique que la table est diffusée à tous les nœuds de calcul. Ceci convient pour une petite table, mais n’est pas idéal pour une table de taille plus importante.
+ **DS\$1DIST\$1ALL\$1INNER** : indique que l’ensemble de la charge de travail est placé sur une seule tranche.
+ **DS\$1DIST\$1BOTH** : indique une redistribution intensive.
Pour connaître les solutions recommandées pour ces situations, consultez [Distribution des données sous-optimales](query-performance-improvement-opportunities.md#suboptimal-data-distribution).
# Analyse du résumé de la requête
Pour obtenir des statistiques et des étapes d’exécution plus détaillées que dans le plan de requête généré par [EXPLAIN](r_EXPLAIN.md), utilisez les vues système [SVL\$1QUERY\$1SUMMARY](r_SVL_QUERY_SUMMARY.md) et [SVL\$1QUERY\$1REPORT](r_SVL_QUERY_REPORT.md).
SVL\$1QUERY\$1SUMMARY fournit des statistiques de requête par flux. Vous pouvez utiliser les informations fournies pour identifier les problèmes posés par les étapes onéreuses, de longue durée et qui écrivent sur le disque.
La vue système SVL\$1QUERY\$1REPORT vous permet de consulter des informations similaires à celles de SVL\$1QUERY\$1SUMMARY, uniquement par tranche de nœuds de calcul, et non par flux. Vous pouvez utiliser les informations au niveau de la tranche pour identifier la distribution inégale de données dans le cluster (également appelée asymétrie de la distribution de données), qui force certains nœuds à travailler davantage que d’autres et affecte les performances des requêtes.
**Topics**
+ [Utilisation de la vue SVL\$1QUERY\$1SUMMARY](using-SVL-Query-Summary.md)
+ [Utilisation de la vue SVL\$1QUERY\$1REPORT](using-SVL-Query-Report.md)
+ [Mappage du plan de requête au résumé de la requête](query-plan-summary-map.md)
# Utilisation de la vue SVL\$1QUERY\$1SUMMARY
Pour analyser les informations récapitulatives sur la requête par flux à l’aide de [SVL\$1QUERY\$1SUMMARY](r_SVL_QUERY_SUMMARY.md), procédez comme suit :
1. Exécutez la requête suivante pour déterminer l’ID de votre requête :
```
select query, elapsed, substring
from svl_qlog
order by query
desc limit 5;
```
Examinez le texte de la requête tronquée dans le champ `substring` pour déterminer quelle valeur de `query` représente votre requête. Si vous avez exécuté la requête plusieurs fois, utilisez la valeur de `query` de la ligne avec la valeur de `elapsed` inférieure. Il s’agit de la ligne de la version compilée. Si vous avez exécuté un grand nombre de requêtes, vous pouvez augmenter la valeur utilisée par la clause LIMIT utilisée pour vous assurer que votre requête est incluse.
1. Sélectionnez les lignes de SVL\$1QUERY\$1SUMMARY pour votre requête. Ordonnez les résultats par flux, par segment et par étape :
```
select * from svl_query_summary where query = MyQueryID order by stm, seg, step;
```
Voici un exemple de résultat.
![\[Exemple de résultat pour les lignes dans SVL_QUERY_SUMMARY correspondant à une requête donnée.\]](http://docs.aws.amazon.com/fr_fr/redshift/latest/dg/images/svl_query_summary_results.png)
1. Mappe les étapes aux opérations du plan de requête à l’aide des informations de [Mappage du plan de requête au résumé de la requête](query-plan-summary-map.md). Elles doivent avoir à peu près les mêmes valeurs pour les lignes et les octets (lignes \$1 largeur dans le plan de requête). Si ce n’est pas le cas, consultez [Statistiques de table manquantes ou obsolètes](query-performance-improvement-opportunities.md#table-statistics-missing-or-out-of-date) pour connaître les solutions recommandées.
1. Vérifiez si le champ `is_diskbased` a une valeur de `t` (true) pour n’importe quelle étape. Les hachages, les agrégats et les tris sont les opérateurs susceptibles d’écrire des données sur le disque si le système ne dispose pas de suffisamment de mémoire allouée pour le traitement des requêtes.
Si `is_diskbased` a la valeur true, consultez [Mémoire insuffisante allouée à la requête](query-performance-improvement-opportunities.md#insufficient-memory-allocated-to-the-query) pour connaître les solutions recommandées.
1. Passez en revue les valeurs des `label` champs et vérifiez s'il existe une AGG-DIST-AGG séquence quelconque dans les étapes. Sa présence indique une agrégation en deux étapes, ce qui est onéreux. Pour résoudre ce problème, modifiez la clause GROUP BY pour utiliser la clé de distribution (la première clé, s’il y en a plusieurs).
1. Vérifiez la valeur de `maxtime` de chaque segment (identique à toutes les étapes du segment). Identifiez le segment ayant la valeur de `maxtime` la plus élevée et vérifiez les étapes de ce segment pour les opérateurs suivants.
**Note**
Une valeur de `maxtime` élevée n’indique pas nécessairement de problème avec le segment. Malgré une valeur élevée, le temps de traitement du segment pourrait ne pas avoir été long. Tous les segments d’un flux sont chronométrés ensemble. Toutefois, certains segments en aval ne sont peut-être pas en mesure de s’exécuter tant qu’ils n’obtiennent pas de données de ceux situés en amont. Cela peut donner l’impression qu’ils ont pris beaucoup de temps, car leur valeur `maxtime` inclura leur temps d’attente et leur temps de traitement.
+ **BCAST ou DIST** : dans ces cas, la valeur de `maxtime` élevée peut être le résultat d’une redistribution d’un grand nombre de lignes. Pour connaître les solutions recommandées, consultez [Distribution des données sous-optimales](query-performance-improvement-opportunities.md#suboptimal-data-distribution).
+ **HJOIN (jointure par hachage)** : si l’étape en question a une valeur très élevée dans le champ `rows` par rapport à la valeur de `rows` dans l’étape RETURN finale dans la requête, consultez [Joindre par hachage](query-performance-improvement-opportunities.md#hash-join) pour connaître les solutions recommandées.
+ **SCAN/SORT** : recherchez une séquence d’étapes SCAN, SORT, SCAN, MERGE juste avant une étape de jointure. Ce modèle indique que des données non triées sont analysées, triées, puis fusionnées avec la région triée de la table.
Vérifiez si la valeur des lignes de l’étape SCAN est très élevée par rapport à la valeur des lignes de l’étape RETURN finale dans la requête. Ce modèle indique que le moteur d’exécution analyse des lignes qui sont ignorées par la suite, ce qui est inefficace. Pour connaître les solutions recommandées, consultez [Prédicat pas assez restrictif](query-performance-improvement-opportunities.md#insufficiently-restrictive-predicate).
Si la valeur `maxtime` de l’étape SCAN est élevée, consultez [Clause WHERE sous-optimale](query-performance-improvement-opportunities.md#suboptimal-WHERE-clause) pour connaître les solutions recommandées.
Si la valeur `rows` de l’étape SORT n’est pas égale à zéro, consultez [Lignes non triées ou mal triées](query-performance-improvement-opportunities.md#unsorted-or-mis-sorted-rows) pour connaître les solutions recommandées.
1. Vérifiez les valeurs `rows` et `bytes` des étapes 5 à 10 précédant l’étape RETURN finale pour savoir quelle est la quantité de données renvoyée au client. Ce processus peut être complexe.
Par exemple, dans l’exemple de requête récapitulative suivant, la troisième étape PROJECT fournit une valeur de `rows`, mais pas une valeur de `bytes`. Les étapes précédentes avec la même valeur de `rows` vous permettront de trouver l’étape SCAN qui fournit des informations sur les lignes et les octets :
Voici un exemple de résultat.
![\[Une ligne des résultats de la requête récapitulative correspond à une étape SCAN avec des informations à la fois sur les lignes et sur les octets.\]](http://docs.aws.amazon.com/fr_fr/redshift/latest/dg/images/rows_and_bytes.png)
Si vous renvoyez un volume inhabituellement élevé de données, consultez [Ensemble de résultats très volumineux](query-performance-improvement-opportunities.md#very-large-result-set) pour connaître les solutions recommandées.
1. Vérifiez si la valeur de `bytes` est élevée par rapport à la valeur de `rows` pour n’importe quelle étape, par rapport aux autres étapes. Ce modèle peut indiquer que vous sélectionnez un grand nombre de colonnes. Pour connaître les solutions recommandées, consultez [Longue liste SELECT](query-performance-improvement-opportunities.md#large-SELECT-list).
# Utilisation de la vue SVL\$1QUERY\$1REPORT
Pour analyser les informations récapitulatives sur la requête par tranche à l’aide de [SVL\$1QUERY\$1REPORT](r_SVL_QUERY_REPORT.md), procédez comme suit :
1. Exécutez la commande suivante pour déterminer l’ID de votre requête :
```
select query, elapsed, substring
from svl_qlog
order by query
desc limit 5;
```
Examinez le texte de la requête tronquée dans le champ `substring` pour déterminer quelle valeur de `query` représente votre requête. Si vous avez exécuté la requête plusieurs fois, utilisez la valeur de `query` de la ligne avec la valeur de `elapsed` inférieure. Il s’agit de la ligne de la version compilée. Si vous avez exécuté un grand nombre de requêtes, vous pouvez augmenter la valeur utilisée par la clause LIMIT utilisée pour vous assurer que votre requête est incluse.
1. Sélectionner des lignes dans SVL\$1QUERY\$1REPORT pour votre requête. Ordonnez les résultats par segment, par étape, par elapsed\$1time et par lignes :
```
select * from svl_query_report where query = MyQueryID order by segment, step, elapsed_time, rows;
```
1. Pour chaque étape, vérifiez que toutes les tranches traitent à peut près le même nombre de lignes :
![\[Liste des tranches de données utilisées pour exécuter une requête. Chaque tranche traite approximativement le même nombre de lignes.\]](http://docs.aws.amazon.com/fr_fr/redshift/latest/dg/images/SVL_QUERY_REPORT_rows.png)
Vérifiez également que toutes les tranches prennent à peu près autant de temps :
![\[Liste des tranches de données utilisées pour exécuter une requête. Chaque tranche prend approximativement le même temps.\]](http://docs.aws.amazon.com/fr_fr/redshift/latest/dg/images/SVL_QUERY_REPORT_elapsed_time.png)
Si ces valeurs sont très différences, cela peut révéler une asymétrie de la distribution des données due à un style de distribution sous-optimal pour cette requête particulière. Pour connaître les solutions recommandées, consultez [Distribution des données sous-optimales](query-performance-improvement-opportunities.md#suboptimal-data-distribution).
# Mappage du plan de requête au résumé de la requête
Lors de l’analyse de la requête récapitulative, vous pouvez obtenir plus de détails en mappant les opérations entre le plan de la requête et les étapes (identifiées par les valeurs du champ d’étiquette) dans le résumé de la requête. La table suivante fait correspondre les opérations du plan de requête aux étapes de la requête récapitulative.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/redshift/latest/dg/query-plan-summary-map.html)
# Amélioration des performances des requêtes
Voici quelques problèmes courants qui affectent les performances des requêtes Amazon Redshift, avec des instructions et des manières de les diagnostiquer et de les résoudre.
**Topics**
+ [Statistiques de table manquantes ou obsolètes](#table-statistics-missing-or-out-of-date)
+ [Boucle imbriquée](#nested-loop)
+ [Joindre par hachage](#hash-join)
+ [Lignes fantômes ou non validées](#ghost-rows-or-uncommitted-rows)
+ [Lignes non triées ou mal triées](#unsorted-or-mis-sorted-rows)
+ [Distribution des données sous-optimales](#suboptimal-data-distribution)
+ [Mémoire insuffisante allouée à la requête](#insufficient-memory-allocated-to-the-query)
+ [Clause WHERE sous-optimale](#suboptimal-WHERE-clause)
+ [Prédicat pas assez restrictif](#insufficiently-restrictive-predicate)
+ [Ensemble de résultats très volumineux](#very-large-result-set)
+ [Longue liste SELECT](#large-SELECT-list)
## Statistiques de table manquantes ou obsolètes
Si des statistiques de la table sont manquantes ou obsolètes, ce qui suit peut s’afficher :
+ Un message d’avertissement dans les résultats de la commande EXPLAIN.
+ Un événement d’alerte de statistiques manquantes dans STL\$1ALERT\$1EVENT\$1LOG. Pour plus d’informations, consultez [Révision des alertes de requêtes](c-reviewing-query-alerts.md).
Pour résoudre ce problème, exécutez [ANALYSE](r_ANALYZE.md).
## Boucle imbriquée
Si une boucle imbriquée est présente, un événement d’alerte de boucle imbriquée peut s’afficher dans STL\$1ALERT\$1EVENT\$1LOG. Vous pouvez également identifier ce type d’événement en exécutant la requête de la section [Identification des requêtes avec des boucles imbriquées](identify-queries-with-nested-loops.md). Pour plus d’informations, consultez [Révision des alertes de requêtes](c-reviewing-query-alerts.md).
Pour résoudre ce problème, vérifiez s’il existe des jointures croisées dans votre requête et supprimez-les si possible. Les jointures croisées sont des jointures sans condition de jointure qui entraînent le produit cartésien de deux tables. Elles sont généralement exécutées en tant que jointures de boucle imbriquée, qui sont les types de jointures les plus lents possibles.
## Joindre par hachage
Si une jointure par hachage est présente, les éléments suivants peuvent s’afficher :
+ Des opérations de hachage et de jointure par hachage dans le plan de la requête. Pour plus d’informations, consultez [Analyse du plan de requête](c-analyzing-the-query-plan.md).
+ Une étape HJOIN dans le segment avec la valeur maxtime la plus élevée dans SVL\$1QUERY\$1SUMMARY. Pour plus d’informations, consultez [Utilisation de la vue SVL\$1QUERY\$1SUMMARY](using-SVL-Query-Summary.md).
Pour résoudre ce problème, vous pouvez adopter deux approches :
+ Réécrivez la requête afin d’utiliser une jointure par fusion si possible. Pour cela, spécifiez les colonnes de jointure qui sont des clés de distribution et des clés de tri.
+ Si l’étape HJOIN de SVL\$1QUERY\$1SUMMARY a une très grande valeur dans le champ des lignes par rapport à la valeur des lignes de l’étape RETURN finale de la requête, vérifiez si vous pouvez réécrire la requête afin d’effectuer une jointure avec une colonne unique. Lorsqu’une requête n’effectue pas de jointure avec une colonne unique, telle qu’une clé primaire, cela augmente le nombre de lignes impliquées dans la jointure.
## Lignes fantômes ou non validées
Si des lignes fantômes ou non validées sont présentes, un événement d’alerte peut s’afficher dans STL\$1ALERT\$1EVENT\$1LOG indiquant un nombre de lignes fantômes excessif. Pour plus d’informations, consultez [Révision des alertes de requêtes](c-reviewing-query-alerts.md).
Pour résoudre ce problème, vous pouvez adopter deux approches :
+ Vérifiez l’onglet **Charges** de votre console Amazon Redshift pour les opérations de charge actives sur l’une des tables de requête. Si vous voyez des opérations de chargement actives, attendez qu’elles se terminent avant d’agir.
+ S’il n’y a aucune opération de charge active, exécutez [VACUUM](r_VACUUM_command.md) sur les tables de la requête pour supprimer les lignes supprimées.
## Lignes non triées ou mal triées
Si des lignes non triées ou mal triées sont présentes, un événement d’alerte de filtre très sélectif peut s’afficher dans STL\$1ALERT\$1EVENT\$1LOG. Pour plus d’informations, consultez [Révision des alertes de requêtes](c-reviewing-query-alerts.md).
Vous pouvez également vérifier si l’une des tables de votre requête présente de grandes zones non triés en exécutant la requête [Identification des tables comportant une asymétrie des données ou des lignes non triées](identify-tables-with-data-skew-or-unsorted-rows.md).
Pour résoudre ce problème, vous pouvez adopter deux approches :
+ Exécutez [VACUUM](r_VACUUM_command.md) sur les tables de requête pour trier à nouveau les lignes.
+ Vérifiez les clés de tri des tables de la requête pour voir si des améliorations peuvent être apportées. N’oubliez pas de comparer les performances de cette requête par rapport aux performances d’autres requêtes importantes et au système global avant toute modification. Pour plus d’informations, consultez [Clés de tri](t_Sorting_data.md).
## Distribution des données sous-optimales
Si la distribution des données est sous-optimale, les éléments suivants peuvent s’afficher :
+ Un événement d’alerte d’exécution en série, de grande diffusion ou de grande distribution s’affiche dans STL\$1ALERT\$1EVENT\$1LOG. Pour plus d’informations, consultez [Révision des alertes de requêtes](c-reviewing-query-alerts.md).
+ Les tranches ne traitent pas le même nombre de lignes (approximativement) pour une étape donnée. Pour plus d’informations, consultez [Utilisation de la vue SVL\$1QUERY\$1REPORT](using-SVL-Query-Report.md).
+ Les tranches ne prennent pas autant de temps (approximativement) pour une étape donnée. Pour plus d’informations, consultez [Utilisation de la vue SVL\$1QUERY\$1REPORT](using-SVL-Query-Report.md).
Si rien de ce qui précède ne s’applique, vous pouvez également vérifier si l’une des tables de votre requête comporte une asymétrie des données en exécutant la requête dans [Identification des tables comportant une asymétrie des données ou des lignes non triées](identify-tables-with-data-skew-or-unsorted-rows.md).
Pour résoudre ce problème, vérifiez les styles de distribution des tables de la requête afin de voir si des améliorations peuvent être apportées. N’oubliez pas de comparer les performances de cette requête par rapport aux performances d’autres requêtes importantes et au système global avant toute modification. Pour plus d’informations, consultez [Distribution de données pour l’optimisation des requêtes](t_Distributing_data.md).
## Mémoire insuffisante allouée à la requête
Si la mémoire allouée à votre requête est insuffisante, vous pouvez voir qu’une étape de SVL\$1QUERY\$1SUMMARY comporte une valeur true pour `is_diskbased`. Pour plus d’informations, consultez [Utilisation de la vue SVL\$1QUERY\$1SUMMARY](using-SVL-Query-Summary.md).
Pour résoudre ce problème, allouez davantage de mémoire à la requête en augmentant temporairement le nombre d’emplacements de requête qu’elle utilise. La gestion de la charge de travail (WLM) réserve des emplacements dans une file d’attente de requête équivalents à au niveau de simultanéité défini pour la file d’attente. Par exemple, une file d’attente avec un niveau de simultanéité de 5 dispose de 5 emplacements. La mémoire affectée à la file d’attente est allouée à part égale à chaque emplacement. L’affectation de plusieurs emplacements à une requête donne à celle-ci accès à la mémoire de tous ces emplacements. Pour plus d’informations sur la procédure permettant d’augmenter temporairement les emplacements d’une requête, consultez [wlm\$1query\$1slot\$1count](r_wlm_query_slot_count.md).
## Clause WHERE sous-optimale
Si votre clause WHERE entraîne des analyses de tables excessives, une étape SCAN peut s’afficher dans le segment ayant la valeur de `maxtime` la plus élevée dans SVL\$1QUERY\$1SUMMARY. Pour plus d’informations, consultez [Utilisation de la vue SVL\$1QUERY\$1SUMMARY](using-SVL-Query-Summary.md).
Pour résoudre ce problème, ajoutez une clause WHERE à la requête basée sur la colonne de tri primaire de la table la plus volumineuse. Cette approche permet de réduire le temps d’analyse. Pour plus d’informations, consultez [Bonnes pratiques Amazon Redshift pour la conception de tables](c_designing-tables-best-practices.md).
## Prédicat pas assez restrictif
Si votre requête a un prédicat qui n’est pas suffisamment restrictif, une étape SCAN peut s’afficher dans le segment avec la valeur de `maxtime` la plus élevée dans SVL\$1QUERY\$1SUMMARY avec une valeur de `rows` très importante par rapport à la valeur de `rows` de l’étape RETURN finale de la requête. Pour plus d’informations, consultez [Utilisation de la vue SVL\$1QUERY\$1SUMMARY](using-SVL-Query-Summary.md).
Pour résoudre ce problème, essayez d’ajouter un prédicat à la requête ou de rendre le prédicat existant plus restrictifs pour affiner les données de sortie.
## Ensemble de résultats très volumineux
Si votre requête renvoie un ensemble de résultats très volumineux, envisagez de réécrire la requête pour utiliser [UNLOAD](r_UNLOAD.md) afin d’écrire les résultats sur Amazon S3. Cette approche permettra d’améliorer les performances de l’étape RETURN en tirant parti du traitement parallèle. Pour plus d’informations sur la recherche d’un ensemble de résultats très volumineux, consultez [Utilisation de la vue SVL\$1QUERY\$1SUMMARY](using-SVL-Query-Summary.md).
## Longue liste SELECT
Si votre requête comporte une liste SELECT inhabituellement longue, une valeur de `bytes` élevée peut s’afficher par rapport à la valeur de `rows` de n’importe quelle étape (comparée à d’autres étapes) dans SVL\$1QUERY\$1SUMMARY. Cette valeur de `bytes` élevée peut indiquer que vous sélectionnez un grand nombre de colonnes. Pour plus d’informations, consultez [Utilisation de la vue SVL\$1QUERY\$1SUMMARY](using-SVL-Query-Summary.md).
Pour résoudre ce problème, vérifiez les colonnes que vous sélectionnez pour voir si certaines peuvent être supprimées.
# Requêtes de diagnostics pour l’ajustement des requêtes
Utilisez les requêtes suivantes pour identifier les problèmes rencontrés par les requêtes ou les tables sous-jacentes susceptibles d’affecter les performances des requêtes. Nous recommandons d’utiliser ces requêtes conjointement aux processus d’ajustement des requêtes expliqués dans la section [Analyse et amélioration des requêtes](c-query-tuning.md).
**Note**
Ces requêtes concernent les clusters alloués Amazon Redshift. Ces requêtes ne sont pas destinées à être utilisées avec les groupes de travail Redshift sans serveur.
**Topics**
+ [Identification des requêtes particulièrement indiquées pour un ajustement](identify-queries-that-are-top-candidates-for-tuning.md)
+ [Identification des tables comportant une asymétrie des données ou des lignes non triées](identify-tables-with-data-skew-or-unsorted-rows.md)
+ [Identification des requêtes avec des boucles imbriquées](identify-queries-with-nested-loops.md)
+ [Vérification des temps d’attente des requêtes dans les files d’attente](review-queue-wait-times-for-queries.md)
+ [Vérification des alertes de requêtes par table](review-query-alerts-by-table.md)
+ [Identification des tables avec des statistiques manquantes](identify-tables-with-missing-statistics.md)
# Identification des requêtes particulièrement indiquées pour un ajustement
La requête suivante identifie les 50 instructions les plus chronophages exécutées au cours des 7 derniers jours. Vous pouvez utiliser les résultats pour identifier les requêtes inhabituellement longues. Vous pouvez également identifier les requêtes exécutées fréquemment (celles qui apparaissent plusieurs fois dans l’ensemble de résultats). Ces requêtes nécessitent souvent un ajustement en vue d’améliorer les performances du système.
Cette requête fournit également un nombre d’événements d’alertes associés à chaque requête identifiée. Ces alertes fournissent des détails utiles pour améliorer les performances de la requête. Pour plus d’informations, consultez [Révision des alertes de requêtes](c-reviewing-query-alerts.md).
```
select trim(database) as db, count(query) as n_qry,
max(substring (qrytext,1,80)) as qrytext,
min(run_minutes) as "min" ,
max(run_minutes) as "max",
avg(run_minutes) as "avg", sum(run_minutes) as total,
max(query) as max_query_id,
max(starttime)::date as last_run,
sum(alerts) as alerts, aborted
from (select userid, label, stl_query.query,
trim(database) as database,
trim(querytxt) as qrytext,
md5(trim(querytxt)) as qry_md5,
starttime, endtime,
(datediff(seconds, starttime,endtime)::numeric(12,2))/60 as run_minutes,
alrt.num_events as alerts, aborted
from stl_query
left outer join
(select query, 1 as num_events from stl_alert_event_log group by query ) as alrt
on alrt.query = stl_query.query
where userid <> 1 and starttime >= dateadd(day, -7, current_date))
group by database, label, qry_md5, aborted
order by total desc limit 50;
```
# Identification des tables comportant une asymétrie des données ou des lignes non triées
La requête suivante identifie les tables comportant une distribution irrégulière de données (asymétrie des données) ou un pourcentage élevé de lignes non triées.
Un valeur de `skew` faible indique que les données de la table sont correctement distribuées. Si une table comporte une valeur de `skew` de 4,00 ou plus, envisagez de modifier le style de distribution de données. Pour plus d’informations, consultez [Distribution des données sous-optimales](query-performance-improvement-opportunities.md#suboptimal-data-distribution).
Si une table comporte une valeur de `pct_unsorted` supérieure à 20 pour cent, envisagez d’exécuter la commande [VACUUM](r_VACUUM_command.md). Pour plus d’informations, consultez [Lignes non triées ou mal triées](query-performance-improvement-opportunities.md#unsorted-or-mis-sorted-rows).
Vous devez également examiner les valeurs de `mbytes` et de `pct_of_total` pour chaque table. Ces colonnes identifient la taille de la table et le pourcentage d’espace sur le disque brut que la table consomme. L’espace disque brut comprend l’espace qui est réservé par Amazon Redshift pour un usage interne, il est donc plus grand que la capacité nominale du disque, qui est la quantité d’espace disque disponible pour l’utilisateur. Ces informations vous permettront de vérifier que l’espace disque est égal à au moins 2,5 fois la taille de votre table la plus volumineuse. Cet espace disponible permet au système d’écrire des résultats intermédiaires sur le disque lors du traitement de requêtes complexes.
```
select trim(pgn.nspname) as schema,
trim(a.name) as table, id as tableid,
decode(pgc.reldiststyle,0, 'even',1,det.distkey ,8,'all') as distkey, dist_ratio.ratio::decimal(10,4) as skew,
det.head_sort as "sortkey",
det.n_sortkeys as "#sks", b.mbytes,
decode(b.mbytes,0,0,((b.mbytes/part.total::decimal)*100)::decimal(5,2)) as pct_of_total,
decode(det.max_enc,0,'n','y') as enc, a.rows,
decode( det.n_sortkeys, 0, null, a.unsorted_rows ) as unsorted_rows ,
decode( det.n_sortkeys, 0, null, decode( a.rows,0,0, (a.unsorted_rows::decimal(32)/a.rows)*100) )::decimal(5,2) as pct_unsorted
from (select db_id, id, name, sum(rows) as rows,
sum(rows)-sum(sorted_rows) as unsorted_rows
from stv_tbl_perm a
group by db_id, id, name) as a
join pg_class as pgc on pgc.oid = a.id
join pg_namespace as pgn on pgn.oid = pgc.relnamespace
left outer join (select tbl, count(*) as mbytes
from stv_blocklist group by tbl) b on a.id=b.tbl
inner join (select attrelid,
min(case attisdistkey when 't' then attname else null end) as "distkey",
min(case attsortkeyord when 1 then attname else null end ) as head_sort ,
max(attsortkeyord) as n_sortkeys,
max(attencodingtype) as max_enc
from pg_attribute group by 1) as det
on det.attrelid = a.id
inner join ( select tbl, max(mbytes)::decimal(32)/min(mbytes) as ratio
from (select tbl, trim(name) as name, slice, count(*) as mbytes
from svv_diskusage group by tbl, name, slice )
group by tbl, name ) as dist_ratio on a.id = dist_ratio.tbl
join ( select sum(capacity) as total
from stv_partitions where part_begin=0 ) as part on 1=1
where mbytes is not null
order by mbytes desc;
```
# Identification des requêtes avec des boucles imbriquées
La requête suivante identifie les requêtes ayant des événements d’alertes consignés pour des boucles imbriquées. Pour plus d’informations sur la façon de corriger la condition de boucle imbriquée, consultez [Boucle imbriquée](query-performance-improvement-opportunities.md#nested-loop).
```
select query, trim(querytxt) as SQL, starttime
from stl_query
where query in (
select distinct query
from stl_alert_event_log
where event like 'Nested Loop Join in the query plan%')
order by starttime desc;
```
# Vérification des temps d’attente des requêtes dans les files d’attente
La requête suivante affiche combien de temps les requêtes récentes ont attendu avant qu’un emplacement s’ouvre dans une file d’attente avant leur exécution. Si vous voyez une tendance de temps d’attente élevés, vous pouvez modifier la configuration de votre file d’attente de requête pour obtenir un débit plus élevé. Pour plus d’informations, consultez [Implémentation de la gestion manuelle de la charge de travail](cm-c-defining-query-queues.md).
```
select trim(database) as DB , w.query,
substring(q.querytxt, 1, 100) as querytxt, w.queue_start_time,
w.service_class as class, w.slot_count as slots,
w.total_queue_time/1000000 as queue_seconds,
w.total_exec_time/1000000 exec_seconds, (w.total_queue_time+w.total_Exec_time)/1000000 as total_seconds
from stl_wlm_query w
left join stl_query q on q.query = w.query and q.userid = w.userid
where w.queue_start_Time >= dateadd(day, -7, current_Date)
and w.total_queue_Time > 0 and w.userid >1
and q.starttime >= dateadd(day, -7, current_Date)
order by w.total_queue_time desc, w.queue_start_time desc limit 35;
```
# Vérification des alertes de requêtes par table
La requête suivante identifie les tables pour lesquelles des événements d’alertes de requêtes ont été consignés, ainsi que les types d’alertes rencontrés le plus souvent.
Si la valeur de `minutes` pour une ligne avec une table identifiée est élevée, vérifiez cette table pour savoir si elle nécessite des opérations de maintenance habituelles, comme l’exécution de [ANALYSE](r_ANALYZE.md) ou de [VACUUM](r_VACUUM_command.md).
Si la valeur de `count` est élevée pour une ligne, mais que la valeur de `table` est null, exécutez une requête sur STL\$1ALERT\$1EVENT\$1LOG pour la valeur de `event` associée afin d’étudier pourquoi cette alerte est déclenchée si souvent.
```
select trim(s.perm_table_name) as table,
(sum(abs(datediff(seconds, s.starttime, s.endtime)))/60)::numeric(24,0) as minutes, trim(split_part(l.event,':',1)) as event, trim(l.solution) as solution,
max(l.query) as sample_query, count(*)
from stl_alert_event_log as l
left join stl_scan as s on s.query = l.query and s.slice = l.slice
and s.segment = l.segment and s.step = l.step
where l.event_time >= dateadd(day, -7, current_Date)
group by 1,3,4
order by 2 desc,6 desc;
```
# Identification des tables avec des statistiques manquantes
La requête suivante fournit un nombre de requêtes que vous exécutez sur les tables pour lesquelles des statistiques sont manquantes. Si cette requête renvoie toutes les lignes, examinez la valeur de `plannode` afin de déterminer la table concernée et exécutez [ANALYSE](r_ANALYZE.md) sur celle-ci.
```
select substring(trim(plannode),1,100) as plannode, count(*)
from stl_explain
where plannode like '%missing statistics%'
group by plannode
order by 2 desc;
```
# Résolution des problèmes
Cette section fournit une référence rapide pour identifier et résoudre certains des problèmes les plus courants et les plus graves que vous êtes susceptibles de rencontrer avec les requêtes Amazon Redshift.
**Topics**
+ [Échecs des connexions](queries-troubleshooting-connection-fails.md)
+ [La requête se bloque](queries-troubleshooting-query-hangs.md)
+ [La requête est trop longue](queries-troubleshooting-query-takes-too-long.md)
+ [La charge échoue](queries-troubleshooting-load-fails.md)
+ [La charge est trop longue](queries-troubleshooting-load-takes-too-long.md)
+ [Le chargement des données est incorrect](queries-troubleshooting-load-data-incorrect.md)
+ [Définition du paramètre de taille d’extraction JDBC](set-the-JDBC-fetch-size-parameter.md)
Ces suggestions vous donnent un point de départ pour le dépannage. Pour plus d’informations, vous pouvez également consulter les ressources suivantes.
Pour plus d’informations sur les changements de comportement dans les fonctionnalités Amazon Redshift susceptibles d’affecter votre application, consultez [Changements de comportement](https://docs.aws.amazon.com/redshift/latest/mgmt/behavior-changes.html).
+ [Accès aux clusters et aux bases de données Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/using-rs-tools.html)
+ [Optimisation automatique des tables](t_Creating_tables.md)
+ [Chargement de données dans Amazon Redshift](t_Loading_data.md)
+ [Didacticiel : chargement des données à partir d’Amazon S3](tutorial-loading-data.md)
# Échecs des connexions
Votre connexion de requête peut échouer pour les raisons suivantes. Nous vous suggérons les approches de résolution des problèmes suivantes.
**Le client ne parvient pas à se connecter au serveur**
Si vous utilisez des certificats SSL ou serveur, commencez par supprimer cette complexité pendant que vous résolvez le problème de connexion. Ensuite, ajoutez à nouveau les certificats SSL ou serveur lorsque vous avez trouvé une solution. Pour plus d’informations, consultez [Configurer les options de sécurité pour les connexions](https://docs.aws.amazon.com/redshift/latest/mgmt/connecting-ssl-support.html) dans le *Guide de gestion Amazon Redshift.*
**La connexion est refusée**
En général, lorsque vous recevez un message d’erreur indiquant qu’il est impossible d’établir une connexion, cela signifie qu’il y a un problème d’autorisation d’accès au cluster. Pour plus d’informations, consultez [La connexion est refusée ou échoue](https://docs.aws.amazon.com/redshift/latest/mgmt/connecting-refusal-failure-issues.html) dans le *Guide de gestion Amazon Redshift.*
# La requête se bloque
Votre requête peut se bloquer, ou cesser de répondre, pour les raisons suivantes. Nous vous suggérons les approches de résolution des problèmes suivantes.
**La connexion à la base de données est abandonnée**
Réduisez la taille de l’unité de transmission maximale (MTU). La taille de la MTU détermine la taille maximale, en octets, d’un paquet pouvant être transféré dans une trame Ethernet sur votre connexion réseau. Pour plus d’informations, consultez [La connexion à la base de données est abandonnée](https://docs.aws.amazon.com/redshift/latest/mgmt/connecting-drop-issues.html) dans le *Guide de gestion Amazon Redshift.*
**La connexion à la base de données arrive à expiration**
La connexion de votre client à la base de données semble se bloquer ou arriver à expiration lorsque vous exécutez de longues requêtes, par exemple une commande COPY. Dans ce cas, vous pouvez constater que la console Amazon Redshift affiche que la requête est terminée, mais que l’outil client lui-même semble toujours exécuter la requête. Les résultats de la requête peuvent être manquants ou incomplets en fonction selon le moment où la connexion s’est arrêtée. Cela se produit lorsque les connexions inactives sont arrêtées par un composant réseau intermédiaire. Pour plus d’informations, consultez [Problème de délai d’expiration du pare-feu](https://docs.aws.amazon.com/redshift/latest/mgmt/connecting-firewall-guidance.html) dans le *Guide de gestion Amazon Redshift.*
**out-of-memoryUne erreur côté client se produit avec ODBC**
Si votre application cliente utilise une connexion ODBC et que votre requête crée un ensemble de résultats trop volumineux pour contenir en mémoire, vous pouvez diffuser l’ensemble de résultats sur votre application cliente à l’aide d’un curseur. Pour plus d’informations, consultez [DECLARE](declare.md) et [Considérations relatives aux performances lors de l’utilisation de curseurs](declare.md#declare-performance).
**out-of-memoryUne erreur côté client se produit avec JDBC**
Lorsque vous tentez de récupérer de grands ensembles de résultats via une connexion JDBC, vous pouvez rencontrer des erreurs côté client out-of-memory. Pour de plus amples informations, veuillez consulter [Définition du paramètre de taille d’extraction JDBC](set-the-JDBC-fetch-size-parameter.md).
**Il existe un blocage potentiel**
En cas de blocage potentiel, essayez ce qui suit :
+ Affichez les tables système [STV\$1LOCKS](r_STV_LOCKS.md) et [STL\$1TR\$1CONFLICT](r_STL_TR_CONFLICT.md) pour rechercher les conflits impliquant des mises à jour de plusieurs tables.
+ Utilisez la fonction [PG\$1CANCEL\$1BACKEND](PG_CANCEL_BACKEND.md) pour annuler une ou plusieurs requêtes conflictuelles.
+ Utilisez la fonction [PG\$1TERMINATE\$1BACKEND](PG_TERMINATE_BACKEND.md) pour mettre fin à une session, ce qui oblige toutes les transactions en cours d’exécution dans la session terminée à libérer tous les verrous et à restaurer la transaction.
+ Planifiez les opérations d’écriture simultanées avec soin. Pour plus d’informations, consultez [Gestion des opérations d’écriture simultanées](c_Concurrent_writes.md).
# La requête est trop longue
Votre requête peut prendre trop de temps pour les raisons suivantes. Nous vous suggérons les approches de résolution des problèmes suivantes.
**Les tables ne sont pas optimisées**
Définissez la clé de tri, le style de distribution et l’encodage de compression des tables afin de tirer pleinement parti du traitement parallèle. Pour de plus amples informations, consultez [Optimisation automatique des tables](t_Creating_tables.md)
**La requête écrit sur le disque**
Vos requêtes peuvent être en train d’écrire sur le disque pendant une partie de l’exécution des requêtes au moins. Pour plus d’informations, consultez [Amélioration des performances des requêtes](query-performance-improvement-opportunities.md).
**La requête doit attendre que d’autres requêtes se terminent**
Vous pouvez améliorer les performances globales du système en créant des files d’attente de requêtes et en affectant différents types de requêtes aux files d’attente correspondantes. Pour plus d’informations, consultez [Gestion de la charge de travail](cm-c-implementing-workload-management.md).
**Les requêtes ne sont pas optimisées**
Analysez le plan EXPLAIN pour rechercher des opportunités de réécriture des requêtes ou d’optimisation de la base de données. Pour plus d’informations, consultez [Création et interprétation d’un plan de requêtes](c-the-query-plan.md).
**La requête nécessite davantage de mémoire pour s’exécuter**
Si une requête spécifique nécessite davantage de mémoire, vous pouvez augmenter la mémoire disponible en augmentant le [wlm\$1query\$1slot\$1count](r_wlm_query_slot_count.md).
**La base de données nécessite une commande VACUUM pour s’exécuter**
Exécutez la commande VACUUM chaque fois que vous ajoutez, supprimez ou modifiez un grand nombre de lignes, sauf si vous chargez vos données dans l’ordre de la clé de tri. La commande VACUUM réorganise vos données afin de conserver l’ordre de tri et de restaurer les performances. Pour plus d’informations, consultez [Exécution de l’opération VACUUM sur les tables](t_Reclaiming_storage_space202.md).
## Ressources supplémentaires pour la résolution des problèmes liés aux requêtes de longue durée
Vous trouverez ci-dessous des rubriques relatives aux vues système et d’autres sections de documentation utiles pour l’ajustement de requêtes :
+ La vue système [STV\$1INFLIGHT](r_STV_INFLIGHT.md) affiche les requêtes qui s’exécutent actuellement sur le cluster. Il peut être utile de l’utiliser avec [STV\$1RECENTS](r_STV_RECENTS.md) pour identifier les requêtes qui s’exécutent actuellement ou qui ont abouti récemment.
+ [SYS\$1QUERY\$1HISTORY](SYS_QUERY_HISTORY.md) est utile pour la résolution des problèmes. Les requêtes DDL et DML y sont présentées avec des propriétés utiles telles que leur statut actuel, comme `running` ou `failed`, la durée d’exécution de chacune d’elles et si une requête s’est exécutée sur un cluster de mise à l’échelle de la simultanéité.
+ [STL\$1QUERYTEXT](r_STL_QUERYTEXT.md) capture le texte de requête pour les commandes SQL. Par ailleurs, [SVV\$1QUERY\$1INFLIGHT](r_SVV_QUERY_INFLIGHT.md), qui joint STL\$1QUERYTEXT à STV\$1INFLIGHT, affiche des métadonnées de requête supplémentaires.
+ Un conflit de verrous de transactions peut être à l’origine de problèmes de performances au niveau des requêtes. Pour en savoir plus sur les transactions qui maintiennent actuellement des verrous sur des tables, consultez [SVV\$1TRANSACTIONS](r_SVV_TRANSACTIONS.md).
+ La rubrique [Identification des requêtes particulièrement indiquées pour un ajustement](https://docs.aws.amazon.com/redshift/latest/dg/diagnostic-queries-for-query-tuning.html#identify-queries-that-are-top-candidates-for-tuning) propose une requête de résolution des problèmes qui vous aide à identifier les requêtes exécutées récemment qui se sont montrées les plus chronophages. Elle vous permet ainsi de porter vos efforts sur les requêtes qui ont besoin d’être améliorées.
+ Si vous souhaitez explorer de manière plus approfondie la gestion des requêtes et comprendre comment gérer les files d’attente de requêtes, la rubrique [Gestion de la charge de travail](cm-c-implementing-workload-management.md) vous montre comment faire. La gestion de la charge de travail étant une fonctionnalité avancée, nous recommandons la gestion automatisée de la charge de travail dans la plupart des cas.
# La charge échoue
Votre chargement de données peut échouer pour les raisons suivantes. Nous vous suggérons les approches de résolution des problèmes suivantes.
**La source de données se trouve dans une autre AWS région**
Par défaut, le compartiment Amazon S3 ou la table Amazon DynamoDB spécifiés dans la commande COPY doivent se trouver dans la AWS même région que le cluster. Si vos données et votre cluster se trouvent dans des régions différentes, vous allez recevoir une erreur similaire à celle-ci :
```
The bucket you are attempting to access must be addressed using the specified endpoint.
```
Si possible, assurez-vous que votre cluster et votre source de données se trouvent dans la même région. Vous pouvez spécifier une autre région à l’aide de l’option [REGION](copy-parameters-data-source-s3.md#copy-region) avec la commande COPY.
**Note**
Si votre cluster et votre source de données se trouvent dans des AWS régions différentes, des frais de transfert de données sont à votre charge. Vous avez également une latence plus élevée.
**La commande COPY échoue**
Interrogez STL\$1LOAD\$1ERRORS pour découvrir les erreurs qui se sont produites lors de charges spécifiques. Pour plus d’informations, consultez [STL\$1LOAD\$1ERRORS](r_STL_LOAD_ERRORS.md).
# La charge est trop longue
Votre opération de chargement peut prendre trop de temps pour les raisons suivantes. Nous vous suggérons les approches de résolution des problèmes suivantes.
**La commande COPY charge les données à partir d’un fichier unique**
Fractionnez les données de chargement en plusieurs fichiers. Lorsque vous chargez toutes les données d’un seul grand fichier, Amazon Redshift est obligé d’effectuer un chargement sérialisé, ce qui est beaucoup plus lent. Le nombre de fichiers doit être un multiple du nombre de tranches de votre cluster, et les fichiers doivent être de taille égale, entre 1 Mo et 1 Go après compression. Pour plus d’informations, consultez [Bonnes pratiques Amazon Redshift pour la conception de requêtes](c_designing-queries-best-practices.md).
**L’opération de chargement utilise plusieurs commandes COPY**
Si vous utilisez plusieurs commandes COPY simultanées pour charger une table à partir de plusieurs fichiers, Amazon Redshift est obligé d’effectuer un chargement sérialisé, ce qui est beaucoup plus lent. Dans ce cas, utilisez une seule commande COPY.
# Le chargement des données est incorrect
Votre opération COPY peut charger des données incorrectes de différentes manières. Nous vous suggérons les approches de résolution des problèmes suivantes.
**Des fichiers incorrects sont chargés**
L’utilisation d’un préfixe d’objet pour spécifier les fichiers de données peut entraîner la lecture de fichiers indésirables. Au lieu de cela, utilisez un fichier manifeste pour spécifier exactement les fichiers à charger. Pour plus d’informations, consultez l’option [copy_from_s3_manifest_file](copy-parameters-data-source-s3.md#copy-manifest-file) pour la commande COPY et [Example: COPY from Amazon S3 using a manifest](r_COPY_command_examples.md#copy-command-examples-manifest) dans les exemples COPY.
# Définition du paramètre de taille d’extraction JDBC
Par défaut, le pilote Redshift JDBC utilise une mémoire tampon en anneau pour gérer efficacement la mémoire et éviter les erreurs. out-of-memory Le paramètre fetch size n'est applicable que lorsque le ring buffer est explicitement désactivé. Pour plus d'informations, consultez le [lien](https://docs.aws.amazon.com/redshift/latest/mgmt/jdbc20-configuration-options.html#jdbc20-enablefetchringbuffer-option). Dans cette configuration, vous devez définir la taille d'extraction pour contrôler le nombre de lignes extraites dans chaque lot.
Utilisez le paramètre fetch size dans les cas suivants :
+ Vous avez besoin d'un contrôle précis sur le traitement par lots par lignes
+ Utilisation d'applications existantes qui nécessitent un comportement de taille d'extraction traditionnel
Lorsque la mémoire tampon en anneau est désactivée, le pilote JDBC collecte tous les résultats d'une requête en une seule fois par défaut. Les requêtes qui renvoient de grands ensembles de résultats peuvent consommer trop de mémoire. Pour récupérer les ensembles de résultats par lots au lieu de les récupérer tous en une seule fois, définissez le paramètre JDBC fetch size dans votre application.
**Note**
La taille de l’extraction n’est pas prise en charge pour ODBC.
Pour obtenir les meilleures performances, définissez la taille de l’extraction sur la valeur la plus élevée qui n’entraîne pas d’erreurs de mémoire. Une valeur d’extraction de taille inférieure entraîne plusieurs opérations du serveur, ce qui prolonge les temps d’exécution. Le serveur réserve des ressources, y compris l’emplacement de requête WLM et la mémoire associée, jusqu’à ce que le client récupère le jeu de résultats complet ou que la requête soit annulée. Lorsque vous ajustez la taille d’extraction de façon appropriée, ces ressources sont libérées plus rapidement, ce qui les rend disponibles pour d’autres requêtes.
**Note**
Si vous devez extraire de grands jeux de données, nous vous recommandons d’utiliser une instruction [UNLOAD](https://docs.aws.amazon.com/redshift/latest/dg/r_UNLOAD.html) pour transférer les données vers Amazon S3. Lorsque vous utilisez UNLOAD, les nœuds de calcul fonctionnent en parallèle afin d’accélérer le transfert des données.
Pour plus d’informations sur la définition du paramètre de taille d’extraction JDBC, consultez [Obtention de résultats basés sur un curseur](https://jdbc.postgresql.org/documentation/query/#getting-results-based-on-a-cursor) dans la documentation de PostgreSQL.