WLMsaut dans la file d'attente des 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.

WLMsaut dans la file d'attente des requêtes

Une requête peut être interrompue en raison d'un WLMdélai d'attente ou d'une action de saut liée à la règle de surveillance des requêtes (QMR). Vous ne pouvez effectuer des requêtes que dans le cadre d'une WLM configuration manuelle.

Lorsqu'une requête est sautée, WLM tente de l'acheminer vers la file d'attente correspondante suivante en fonction des règles d'attribution de WLM file d'attente. Si la requête ne correspond à aucune autre définition de file d’attente, elle est annulée. Elle n’est pas affectée à la file d’attente par défaut.

WLMactions de temporisation

Le tableau suivant récapitule le comportement de différents types de requêtes présentant un WLM délai d'expiration.

Type de requête Action
INSERT,UPDATE, et DELETE Annuler
Fonctions définies par l'utilisateur () UDFs Annuler
UNLOAD Annuler
COPY Continuer l’exécution
Opérations de maintenance Continuer l’exécution
Requêtes en lecture seule dans un état de returning Continuer l’exécution
Requêtes en lecture seule dans un état de running Réaffecter ou redémarrer
CREATETABLEEN TANT QUE (CTAS), SELECT INTO Réaffecter ou redémarrer

WLMdépassement de la file d'attente

WLMlance les types de requêtes suivants lorsqu'ils expirent :

  • Requêtes en lecture seule, telles que les SELECT instructions, dont WLM l'état est égal à. running Pour connaître l'WLMétat d'une requête, consultez la STATE colonne de la table STV_WLM_QUERY_STATE système.

  • CREATETABLEdéclarations AS (CTAS). WLMle saut de file d'attente prend en charge les instructions définies par l'utilisateur et générées par le systèmeCTAS.

  • SELECTINTOdéclarations.

Les requêtes qui ne sont pas soumises à un WLM délai d'expiration continuent de s'exécuter dans la file d'attente d'origine jusqu'à ce qu'elles soient terminées. Les types de requêtes suivants ne sont pas soumis à un WLM délai d'expiration :

  • COPYdéclarations

  • Les opérations de maintenance, telles que ANALYZE et VACUUM

  • Requêtes en lecture seule, telles que les SELECT instructions, qui ont atteint WLM l'état de. returning Pour connaître l'WLMétat d'une requête, consultez la STATE colonne de la table STV_WLM_QUERY_STATE système.

Les requêtes qui ne sont pas éligibles au saut par WLM délai d'expiration sont annulées lorsqu'elles expirent. Les types de requêtes suivants ne sont pas éligibles au saut avant WLM expiration :

  • INSERTUPDATE, et DELETE déclarations

  • UNLOADdéclarations

  • Fonctions définies par l'utilisateur () UDFs

WLMdélai d'attente, réaffectation et requêtes redémarrées

Lorsqu’une requête est replacée et qu’aucune file d’attente correspondante n’est trouvée, celle-ci est annulée.

Lorsqu'une requête est sautée et qu'une file d'attente correspondante est trouvée, WLM tente de réaffecter la requête à la nouvelle file d'attente. Si une requête ne peut être réaffectée, elle est redémarrée dans la nouvelle file d’attente, comme décrit ci-après.

Une requête est affectée uniquement si toutes les conditions suivantes sont vraies :

  • Une file d’attente correspondante a été trouvée.

  • La nouvelle file d’attente dispose de suffisamment d’emplacements libres pour exécuter la requête. Une requête peut nécessiter plusieurs emplacements si le paramètre wlm_query_slot_count a été défini sur une valeur supérieure à 1.

  • La nouvelle file d’attente dispose d’au moins autant de mémoire disponible que la requête en utilise actuellement.

Si la requête est réaffectée, celle-ci continue à s’exécuter dans la nouvelle file d’attente. Les résultats intermédiaires sont préservés, de sorte que l’impact sur le temps d’exécution total est minime.

Si la requête ne peut être réaffectée, elle est annulée et redémarrée dans la nouvelle file d’attente. Les résultats intermédiaires sont supprimés. La requête attend dans la file d’attente, puis commence à s’exécuter lorsque suffisamment d’emplacements sont disponibles.

QMRActions d'achat

Le tableau suivant récapitule le comportement de différents types de requêtes avec une action de QMR saut.

Type de requête Action
COPY Continuer l’exécution
Opérations de maintenance Continuer l’exécution
Fonctions définies par l'utilisateur () UDFs Continuer l’exécution
UNLOAD Réaffecter ou continuer l’exécution
INSERT,UPDATE, et DELETE Réaffecter ou continuer l’exécution
Requêtes en lecture seule dans un état de returning Réaffecter ou continuer l’exécution
Requêtes en lecture seule dans un état de running Réaffecter ou redémarrer
CREATETABLEEN TANT QUE (CTAS), SELECT INTO Réaffecter ou redémarrer

Pour savoir si une requête saisie a QMR été réaffectée, redémarrée ou annulée, interrogez la table des journaux du STL_WLM_RULE_ACTION système.

QMRaction hop réassignée et requêtes redémarrées

Lorsqu’une requête est replacée et qu’aucune file d’attente correspondante n’est trouvée, celle-ci est annulée.

Lorsqu'une requête est sautée et qu'une file d'attente correspondante est trouvée, WLM tente de réaffecter la requête à la nouvelle file d'attente. Si une requête ne peut être réaffectée, elle est redémarrée dans la nouvelle file d’attente ou continue de s’exécuter dans la file d’attente d’origine, comme décrit ci-après.

Une requête est affectée uniquement si toutes les conditions suivantes sont vraies :

  • Une file d’attente correspondante a été trouvée.

  • La nouvelle file d’attente dispose de suffisamment d’emplacements libres pour exécuter la requête. Une requête peut nécessiter plusieurs emplacements si le paramètre wlm_query_slot_count a été défini sur une valeur supérieure à 1.

  • La nouvelle file d’attente dispose d’au moins autant de mémoire disponible que la requête en utilise actuellement.

Si la requête est réaffectée, celle-ci continue à s’exécuter dans la nouvelle file d’attente. Les résultats intermédiaires sont préservés, de sorte que l’impact sur le temps d’exécution total est minime.

Si une requête ne peut être réaffectée, elle est redémarrée ou continue de s’exécuter dans la file d’attente d’origine. Si la requête est redémarrée, elle est annulée et redémarrée dans la nouvelle file d’attente. Les résultats intermédiaires sont supprimés. La requête attend dans la file d’attente, puis commence à s’exécuter lorsque suffisamment d’emplacements sont disponibles.