Utilisation de la SUMMARY vue SVL QUERY _ _ - Amazon Redshift

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.

Utilisation de la SUMMARY vue SVL QUERY _ _

Pour analyser les informations récapitulatives des requêtes par flux en utilisantSVL_QUERY_SUMMARY, 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é de nombreuses requêtes, vous pouvez augmenter la valeur utilisée par la LIMIT clause utilisée pour vous assurer que votre requête est incluse.

  2. Sélectionnez les lignes de SVL _ QUERY _ SUMMARY 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 de SVL _ QUERY _ SUMMARY correspondant à une requête donnée.

  3. 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. Elles doivent avoir à peu près les mêmes valeurs pour les lignes et les octets (lignes * largeur dans le plan de requête). Si ce n’est pas le cas, consultez Statistiques de table manquantes ou obsolètes pour connaître les solutions recommandées.

  4. 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 pour connaître les solutions recommandées.

  5. 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 afin d'utiliser la clé de distribution (la première clé, s'il y en a plusieurs).

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

    • BCASTou DIST : Dans ces cas, la maxtime valeur élevée peut être le résultat de la redistribution d'un grand nombre de lignes. Pour connaître les solutions recommandées, consultez Distribution des données sous-optimales.

    • HJOIN(jointure par hachage) : si le rows champ de l'étape en question contient une valeur très élevée par rapport à la rows valeur de l'RETURNétape finale de la requête, consultez Joindre par hachage les solutions recommandées.

    • SCAN/SORT: Recherchez une MERGE séquence d'étapes SCAN SORTSCAN,, 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'SCANétape est très élevée par rapport à la valeur des lignes de la dernière RETURN étape de 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.

      Si la maxtime valeur de l'SCANétape est élevée, consultez Clause sous-optimale WHERE les solutions recommandées.

      Si la rows valeur de l'SORTétape n'est pas nulle, consultez Lignes non triées ou mal triées les solutions recommandées.

  7. Passez en revue les bytes valeurs rows et des 5 à 10 étapes qui précèdent la dernière RETURN étape pour avoir une idée de la quantité de données renvoyée au client. Ce processus peut être complexe.

    Par exemple, dans l'exemple de résumé de requête suivant, la troisième PROJECT étape fournit une rows valeur, mais pas de bytes valeur. En parcourant les étapes précédentes pour en trouver une ayant la même rows valeur, vous trouverez l'SCANétape qui fournit à la fois des informations sur les lignes et les octets.

    Voici un exemple de résultat.

    Une ligne du résumé de la requête correspond à une SCAN étape contenant à la fois des informations sur les lignes et les octets.

    Si vous renvoyez un volume inhabituellement élevé de données, consultez Ensemble de résultats très volumineux pour connaître les solutions recommandées.

  8. 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 Grande SELECT liste.