Pourquoi ma requête a-t-elle été interrompue dans Amazon Redshift ?

Dernière mise à jour : 28/07/2021

Ma requête dans Amazon Redshift a été interrompue avec un message d'erreur. Pourquoi ma requête a-t-elle été abandonnée ?

Brève description

Une requête peut être interrompue dans Amazon Redshift pour les raisons suivantes :

  • Configuration des règles de surveillance des requêtes Amazon Redshift Workload Management (WLM)
  • Valeur de délai d'attente d'instruction
  • Requêtes ABORT, CANCEL ou TERMINATE
  • Problèmes de réseau
  • Mises à niveau de maintenance de cluster
  • Erreurs de traitement interne
  • Erreurs ASSERT

Pour empêcher l'abandon de votre requête, considérez les approches suivantes :

Résolution

Configuration des règles Amazon Redshift Workload Management (WLM)

Vous pouvez créer des règles de surveillance des requêtes (QMR, Query Monitoring Rules) WLM pour définir des limites de performances basées sur des mesures pour vos files d'attente. Vous pouvez également spécifier les actions qu'Amazon Redshift doit entreprendre lorsqu'une requête dépasse les limites de temps WLM. Par exemple, vous pouvez créer une règle qui abandonne les requêtes qui sont exécutées pendant plus de 60 secondes.

Exemple 1 : action « Abort » spécifiée dans la règle de surveillance des requêtes

Si une requête est abandonnée en raison de l'action « Abort » spécifiée dans une règle de surveillance des requêtes, la requête renvoie l'erreur suivante :

ERROR:  Query (500029) cancelled by WLM abort action of Query Monitoring Rule "testrule".

Pour identifier si une requête a été abandonnée en raison d'une action « Abort », exécutez la requête suivante :

select * from STL_WLM_RULE_ACTION where action = 'abort';

La sortie de la requête répertorie toutes les requêtes interrompues par l'action « Abort ». Si votre ID de requête est répertorié dans la sortie, augmentez la limite de temps dans le paramètre WLM QMR.

Exemple 2 : aucune file d'attente disponible pour la requête à replacer

Une requête peut être replacée si l'action « Hop » est spécifiée dans la règle de surveillance des requêtes. Lorsqu'une requête est replacée, WLM tente d'acheminer la requête vers la file d'attente correspondante suivante, en fonction des règles d'attribution de file d'attente WLM. Si la requête ne correspond pas à une définition de file d'attente, la requête est annulée. Une requête annulée n'est pas réaffectée à la file d'attente par défaut. Pour plus d'informations sur le comportement du délai d'attente WLM, consultez la section Propriétés du paramètre wlm_json_configuration.

Remarque : vous pouvez replacer les requêtes uniquement dans une configuration WLM manuelle.

Si une requête est replacée, mais qu'aucune file d'attente correspondante n'est disponible, la requête annulée renvoie le message d'erreur suivant :

ERROR: Query (500104) canceled on user's request and ran out of wlm queues for restart.

Si votre requête est abandonnée avec ce message d'erreur, vérifiez les files d'attente définies par l'utilisateur :

select * from stl_wlm_query where query=<query-id>;

Dans votre sortie, les entrées service_class 6-13 incluent les files d'attente définies par l'utilisateur. Par exemple, service_class 6 peut répertorier Queue1 dans la configuration WLM, et service_class 7 peut répertorier Queue2.

Pour obtenir plus d'informations sur le paramètre service_class pour le mappage de file d'attente, exécutez la requête suivante :

select * from stv_wlm_service_class_config where service_class>5;

Après avoir obtenu les informations de mappage de file d'attente, vérifiez la configuration WLM à partir de la console Amazon Redshift. Vérifiez si les files d'attente correspondent aux files d'attente définies dans la configuration WLM. Une requête ne peut être replacée que si une file d'attente correspondante est disponible pour la configuration du groupe d'utilisateurs ou du groupe de requêtes. Pour plus d'informations, consultez la section Déplacement de files d'attente de requêtes WLM.

Valeur de délai d'attente d'instruction

La valeur statement_timeout est la durée maximale pendant laquelle une requête peut être exécutée avant qu'Amazon Redshift ne mette fin à celle-ci. Lorsqu'un délai d'attente d'instruction est dépassé, les requêtes soumises pendant la session sont annulées avec le message d'erreur suivant :

ERROR:  Query (150) cancelled on user's request

Pour vérifier si une requête a été abandonnée en raison d'un délai d'attente d'instruction, exécutez la requête suivante :

select * from SVL_STATEMENTTEXT where text ilike '%set%statement_timeout%to%' and pid in (select pid from STL_QUERY where query = <queryid>);

Les délais d'attente d'instruction peuvent également être définis dans le groupe de paramètres de cluster. Vérifiez votre groupe de paramètres de cluster et tous les paramètres de configuration statement_timeout pour une confirmation supplémentaire. Pour plus d'informations sur le groupe de paramètres de cluster et les paramètres statement_timeout, consultez la section Modification d'un groupe de paramètres.

Requêtes ABORT, CANCEL ou TERMINATE

Pour vérifier si une requête particulière a été abandonnée ou annulée par un utilisateur (tel qu'un superutilisateur), exécutez la commande suivante avec votre ID de requête :

select * from SVL_STATEMENTTEXT where text ilike '%cancel%' and xid 
    in (select xid from STL_QUERY where query = <queryid>);
select * from SVL_STATEMENTTEXT where text ilike '%abort%' and xid in (select xid from STL_QUERY where query = <queryid>);
Si la requête apparaît dans la sortie, cela signifie que celle-ci a été abandonnée ou annulée à la demande de l'utilisateur.

Remarque : les utilisateurs ne peuvent mettre fin qu'à leur propre session. Un superutilisateur peut mettre fin à toutes les sessions.

Les requêtes peuvent également être abandonnées lorsqu'un utilisateur annule ou arrête un processus correspondant (alors que la requête est en cours d'exécution). Voici des exemples de processus correspondants qui peuvent annuler ou abandonner une requête :

Lorsqu'un processus est annulé ou arrêté par ces commandes, une entrée est enregistrée dans SVL_TERMINATE. Pour confirmer si une requête a été abandonnée en raison de l'arrêt d'une session correspondante, vérifiez les journaux SVL_TERMINATE :

select * from SVL_TERMINATE where pid=(select pid from STL_QUERY where query=500534);

Problèmes de réseau

Parfois, les requêtes sont abandonnées en raison de problèmes réseau sous-jacents. Pour vérifier si les problèmes réseau provoquent l'abandon de votre requête, vérifiez les entrées STL_CONNECTION_LOG :

select * from STL_CONNECTION_LOG where pid in (select pid from STL_QUERY where query = <query_id>);
STL_CONNECTION_LOG enregistre les tentatives d'authentification et les déconnexions ou connexions réseau. Si votre requête apparaît dans la sortie, cela signifie qu'un problème de connexion réseau peut entraîner l'abandon de votre requête.

Mises à niveau de maintenance de cluster

Si une maintenance planifiée se produit pendant qu'une requête est en cours d'exécution, la requête est interrompue et annulée, ce qui nécessite le redémarrage du cluster. Planifiez des opérations de longue durée (telles que des charges de données importantes ou l'opération VACUUM ) pour éviter les fenêtres de maintenance. Pour plus d'informations, consultez la section Planification autour des fenêtres de maintenance.

Pour vérifier si la maintenance a été effectuée sur votre cluster Amazon Redshift, sélectionnez l'onglet Événements de votre console Amazon Redshift.

Erreurs de traitement interne

La table STL_ERROR enregistre les erreurs de traitement internes générées par Amazon Redshift. La table STL_ERROR n'enregistre pas les erreurs ou les messages SQL.

Pour vérifier si votre requête a été abandonnée par une erreur interne, vérifiez les entrées STL_ERROR :

select * from STL_ERROR where userid=<user id>;

Erreurs ASSERT

Parfois, les requêtes sont abandonnées en raison d'une erreur ASSERT. L'erreur ASSERT peut se produire en cas de problème avec la requête elle-même. Si vous obtenez une erreur ASSERT après une mise à niveau du correctif, mettez à jour Amazon Redshift vers la dernière version du cluster. Ensuite, vérifiez l'historique des versions du cluster. Vous pouvez également restaurer la version du cluster.


Cet article vous a-t-il été utile ?


Besoin d'aide pour une question technique ou de facturation ?