Révision des alertes de requêtes - 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.

Révision des alertes de requêtes

Pour utiliser la table système STL_ALERT_EVENT_LOG 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é 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 STL _ ALERT _ EVENT _ LOG pour votre requête :

    Select * from stl_alert_event_log where query = MyQueryID;
    Exemple de résultat de requête provenant de STL _ ALERT _ EVENT _LOG.

  3. 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 comportent pas de lignes dans STL ALERT _ _ EVENT _LOG, mais uniquement celles présentant des problèmes identifiés.

    Problème Valeur de l’événement Valeur de la solution Solution recommandée
    Les statistiques des tables de la requête sont manquantes ou ne sont pas à jour. Statistiques du planificateur de requête manquantes Exécutez la ANALYZE commande Consultez Statistiques de table manquantes ou obsolètes.
    Le plan de requête contient une jointure de boucle imbriquée (la jointure la moins optimale). Jointure de boucle imbriquée dans le plan de requête Vérifiez les prédicats de jointure pour éviter les produits cartésiens Consultez Boucle imbriquée.
    L’analyse a ignoré un certain nombre de lignes qui sont marquées comme supprimées, mais pas vidées, ou des lignes qui ont été ajoutées mais pas la validées. Analyse d’un grand nombre de lignes supprimées Exécutez la VACUUM commande pour récupérer l'espace supprimé Consultez Lignes fantômes ou non validées.
    Plus de 1 000 000 de lignes ont été redistribuées pour une jointure par hachage ou une agrégation. Distribution d'un grand nombre de lignes sur le réseau : des RowCount lignes ont été distribuées afin de traiter l'agrégation Vérifiez le choix de clé de distribution pour colocaliser la jointure ou l’agrégation Consultez Distribution des données sous-optimales.
    Plus de 1 000 000 de lignes ont été diffusées pour une jointure par hachage. Diffusion d’un grand nombre de lignes sur le réseau Vérifiez le choix de clé de distribution pour colocaliser la jointure et pensez à utiliser des tables distribuées Consultez Distribution des données sous-optimales.
    Un style de INNER redistribution DIST DS_ ALL _ _ a été indiqué dans le plan de requête, ce qui force l'exécution en série car l'intégralité de la table interne a été redistribuée à un seul nœud. DS_ _ DIST ALL _ INNER pour Hash Join dans le plan de requête Vérifiez le choix de stratégie de distribution pour distribuer la table interne, plutôt qu’externe Consultez Distribution des données sous-optimales.