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.
# STL\$1ALERT\$1EVENT\$1LOG
Enregistre une alerte quand l’optimiseur de requête identifie les conditions qui peuvent indiquer des problèmes de performances. Utilisez la vue STL\$1ALERT\$1EVENT\$1LOG pour identifier les opportunités d’améliorer les performances des requêtes.
Une requête se compose de plusieurs segments et chaque segment d’une ou de plusieurs étapes. Pour plus d'informations, consultez [Traitement des requêtes](c-query-processing.md).
STL\$1ALERT\$1EVENT\$1LOG est visible par tous les utilisateurs. Les super-utilisateurs peuvent voir toutes les lignes, tandis que les utilisateurs standard peuvent voir uniquement leurs propres données. Pour plus d’informations, consultez [Visibilité des données dans les tables et vues système](cm_chap_system-tables.md#c_visibility-of-data).
**Note**
STL\$1ALERT\$1EVENT\$1LOG ne contient que les requêtes exécutées sur les clusters alloués principaux. Elle ne contient pas de requêtes exécutées sur des clusters de mise à l’échelle de la simultanéité ou sur des espaces de noms sans serveur. Pour accéder aux plans d’explication de requêtes exécutées à la fois sur les clusters principaux, sur les clusters de mise à l’échelle de la simultanéité et sur des espaces de noms sans serveur, nous vous recommandons d’utiliser la vue de surveillance SYS [SYS\$1QUERY\$1DETAIL](SYS_QUERY_DETAIL.md). Les données de la vue de surveillance SYS sont formatées pour être plus faciles à utiliser et à comprendre.
## Colonnes de la table
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/redshift/latest/dg/r_STL_ALERT_EVENT_LOG.html)
## Notes d’utilisation
Vous pouvez utiliser STL\$1ALERT\$1EVENT\$1LOG pour identifier les problèmes potentiels de votre requête, puis suivre les pratiques décrites dans [Réglage de performances des requêtes](c-optimizing-query-performance.md) afin d’optimiser la conception de votre base de données et de réécrire vos requêtes. STL\$1ALERT\$1EVENT\$1LOG enregistre les alertes suivantes :
+ **Statistiques manquantes**
Il manque des statistiques. Exécutez ANALYZE après les chargements de données ou les mises à jour importantes, et utilisez STATUPDATE avec les opérations COPY. Pour plus d'informations, consultez [Bonnes pratiques Amazon Redshift pour la conception de requêtes](c_designing-queries-best-practices.md).
+ **Boucle imbriquée**
Une boucle imbriquée est généralement un produit cartésien. Évaluez votre requête afin de vous assurer que toutes les tables participantes sont unies efficacement.
+ **Filtre très sélectif**
Le rapport entre le nombre de lignes retournées et le nombre de lignes analysées est inférieur à 0,05. Le nombre de lignes analysées est la valeur de `rows_pre_user_filter` et le nombre de lignes renvoyées est la valeur de lignes dans la vue système [STL\$1SCAN](r_STL_SCAN.md). Indique que la requête analyse un nombre inhabituellement grand de lignes pour déterminer le jeu de résultats. La raison peut en être des clés de tri manquantes ou incorrectes. Pour plus d'informations, consultez [Clés de tri](t_Sorting_data.md).
+ **Lignes fantôme excessives **
Une analyse a ignoré un nombre relativement grand de lignes marquées comme supprimées, mais pas vidées, ou de lignes qui ont été insérées, mais pas validées. Pour plus d'informations, consultez [Exécution de l’opération VACUUM sur les tables](t_Reclaiming_storage_space202.md).
+ **Grande Distribution **
Plus de 1 000 000 de lignes ont été redistribuées pour une jointure par hachage ou une agrégation. Pour plus d'informations, consultez [Distribution de données pour l’optimisation des requêtes](t_Distributing_data.md).
+ **Large diffusion **
Plus de 1 000 000 de lignes ont été diffusées pour une jointure par hachage. Pour plus d'informations, consultez [Distribution de données pour l’optimisation des requêtes](t_Distributing_data.md).
+ **Exécution en série**
Un style de redistribution DS\$1DIST\$1ALL\$1INNER a été indiqué dans le plan de requête, ce qui force une exécution en série, car la totalité de la table interne a été redistribuée sur un seul nœud. Pour plus d'informations, consultez [Distribution de données pour l’optimisation des requêtes](t_Distributing_data.md).
## Exemples de requêtes
La requête suivante affiche les événements d’alerte pour quatre requêtes.
```
SELECT query, substring(event,0,25) as event,
substring(solution,0,25) as solution,
trim(event_time) as event_time from stl_alert_event_log order by query;
query | event | solution | event_time
-------+-------------------------------+------------------------------+---------------------
6567 | Missing query planner statist | Run the ANALYZE command | 2014-01-03 18:20:58
7450 | Scanned a large number of del | Run the VACUUM command to rec| 2014-01-03 21:19:31
8406 | Nested Loop Join in the query | Review the join predicates to| 2014-01-04 00:34:22
29512 | Very selective query filter:r | Review the choice of sort key| 2014-01-06 22:00:00
(4 rows)
```