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

Brève description

Une requête peut être annulée dans Amazon Redshift pour les raisons suivantes :

• Configuration des règles de surveillance des requêtes de charge de travail Amazon Redshift (WLM)
• Valeur du délai d'expiration de la déclaration
• Demandes d'ABROGATION, D'ANNULATION ou DE FIN
• Problèmes liés au réseau
• Améliorations de maintenance du cluster
• Erreurs de traitement internes
• Erreurs ASSERT

Pour empêcher l'arrêt de votre requête, procédez comme suit :

• Augmentez votre paramètre de délai d'expiration.
• Mettez à jour vos règles WLM QMR.
• Planifiez des opérations de longue durée en dehors des créneaux de maintenance.

Résolution

Configuration des règles de surveillance des requêtes Amazon Redshift WLM

Créez des règles de surveillance des requêtes (QMR) WLM pour définir des limites de performance basées sur des métriques pour vos files d'attente. Vous pouvez également spécifier les actions entreprises par Amazon Redshift lorsqu'une requête dépasse les limites de temps WLM. Par exemple, créez une règle qui annule les requêtes exécutées pendant plus de 60 secondes.

Exemple 1 : Abandonner l'action spécifiée dans la règle de surveillance des requêtes

Si une requête est annulée en raison de l'action d'abandon 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 savoir si une requête a été annulée en raison d'une action « d'abandon », 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 annulées par l'action « abandonner ». 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 à sauter

Une requête peut être sautée si l'action « saut » est spécifiée dans la règle de surveillance des requêtes. Lorsqu'une requête est sautée, WLM tente d'acheminer la requête vers la file d'attente correspondante suivante en fonction des règles d'attribution des files d'attente WLM. Si la requête ne correspond pas à la définition d'une file d'attente, elle 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, consultez la section Propriétés du paramètre wlm_json_configuration.

Remarque : Vous ne pouvez sauter des requêtes que dans une configuration WLM manuelle.

Si une requête est sauté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 annulée avec ce message d'erreur, exécutez la requête suivante pour vérifier 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, le service_class 6 peut répertorier la file d'attente 1 dans la configuration WLM et le service_class 7 peut répertorier la file d'attente 2.

Exécutez la requête suivante pour plus d'informations sur le mappage entre le service_class et la file d'attente :

select * from stv_wlm_service_class_config where service_class>5;

Après avoir obtenu les informations de mappage des files d'attente, vérifiez la configuration WLM depuis la console Amazon Redshift. Vérifiez que les files d'attente correspondent à la configuration WLM. Vous ne pouvez accéder à une requête 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 saut de file d'attente de requêtes WLM.

Valeur du délai d'expiration de la déclaration

La valeur de l'instruction_timeout correspond à la durée maximale pendant laquelle une requête s'exécute avant qu'Amazon Redshift n'y mette fin. Lorsque le délai d'expiration d'une instruction est dépassé, les requêtes soumises pendant la session sont annulées avec le message d'erreur suivant :

« ERREUR : Requête (150) annulée à la demande de l'utilisateur »

Pour vérifier si une requête a été annulée en raison du délai d'expiration d'une 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'expiration des instructions peuvent également être définis dans le groupe de paramètres du cluster. Vérifiez votre groupe de paramètres de cluster et tous les paramètres de configuration de la déclaration_timeout pour obtenir une confirmation supplémentaire. Pour plus d'informations, consultez la section Modification d'un groupe de paramètres.

Demandes d'ABROGATION, D'ANNULATION ou DE FIN

Pour vérifier si une requête particulière a été arrêtée ou annulée par un utilisateur (tel qu'un super-utilisateur), exécutez la requête 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, elle a été arrêtée ou annulée à la demande de l'utilisateur.

Remarque : Les utilisateurs peuvent uniquement mettre fin à leur propre session. Un super utilisateur peut mettre fin à toutes les sessions.

Les requêtes peuvent également être interrompues lorsqu'un utilisateur annule ou met fin à un processus correspondant (dans lequel la requête est en cours d'exécution). Voici des exemples de processus permettant d'annuler ou de terminer une requête :

• PG_TERMINATE_BACKEND
• PG_CANCEL_BACKEND
• ANNULER

Lorsqu'un processus est annulé ou terminé par ces commandes, une entrée est enregistrée dans le journal SVL_TERMINATE. Pour vérifier si une requête a été arrêtée en raison de la fermeture d'une session, consultez les journaux SVL_TERMINATE. Exécutez la requête suivante pour vérifier les journaux SVL_TERMINATE :

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

Problèmes liés au réseau

Les requêtes sont parfois annulées en raison de problèmes réseau sous-jacents. Pour vérifier si des problèmes de réseau sont à l'origine de l'annulation de votre requête, exécutez la requête suivante pour vérifier les entrées STL_CONNECTION_LOG :

select * from STL_CONNECTION_LOG where pid in (select pid from STL_QUERY where query = <query_id>);

Le STL_CONNECTION_LOG enregistre les tentatives d'authentification et les connexions ou déconnexions réseau. Si votre requête apparaît dans la sortie, il se peut qu'un problème de connexion réseau soit à l'origine de l'annulation de votre requête.

Améliorations de maintenance du cluster

Si une maintenance planifiée a lieu alors qu'une requête est en cours d'exécution, la requête est interrompue et annulée, ce qui nécessite un redémarrage du cluster. Planifiez des opérations de longue durée (telles que des chargements de données importants ou l'opération VACUUM) pour éviter les fenêtres de maintenance. Pour plus d'informations, voir Planification en fonction des fenêtres de maintenance.

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

Erreurs de traitement internes

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 SQL ni les messages.

Pour vérifier si votre requête a été annulée par une erreur interne, exécutez la requête suivante pour vérifier les entrées STL_ERROR :

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

Erreurs ASSERT

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