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.
# SVCS\_ALERT\_EVENT\_LOG
Enregistre une alerte quand l’optimiseur de requête identifie les conditions qui peuvent indiquer des problèmes de performances. Cette vue est dérivée de la table système STL\_ALERT\_EVENT\_LOG, mais n’affiche pas le niveau tranche pour les requêtes exécutées sur un cluster de mise à l’échelle de la simultanéité. Utilisez la table SVCS\_ALERT\_EVENT\_LOG 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 de plus amples informations, veuillez consulter [Traitement des requêtes](c-query-processing.md).
**Note**
Les vues système dotées du préfixe SVCS fournissent des détails à propos des requêtes sur le cluster principal et les clusters de mise à l’échelle de la simultanéité. Elles sont similaires aux tables dotées du préfixe STL, si ce n’est que les tables STL fournissent des informations uniquement pour les requêtes exécutées sur le cluster principal.
SVCS\_ALERT\_EVENT\_LOG 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).
## Colonnes de la table
[See the AWS documentation website for more details](http://docs.aws.amazon.com/fr_fr/redshift/latest/dg/r_SVCS_ALERT_EVENT_LOG.html)
## Notes d’utilisation
Vous pouvez utiliser SVCS\_ALERT\_EVENT\_LOG 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. SVCS\_ALERT\_EVENT\_LOG 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. La valeur des lignes analysées est `rows_pre_user_filter ` et celle des lignes retournées la valeur des lignes dans la table système [STL\_SCAN](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\_DIST\_ALL\_INNER 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 svcs_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)
```