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

Avec Amazon Redshift, vous pouvez gérer la simultanéité de la charge de travail et l'allocation des ressources en activant le saut dans la file d'attente des requêtes WLM (gestion de la charge de travail). Cette fonctionnalité permet aux requêtes de « passer » temporairement d'une file d'attente assignée à une file d'attente plus prioritaire lorsque des ressources sont disponibles, améliorant ainsi les performances globales des requêtes et l'utilisation du système. Les sections suivantes fournissent des instructions détaillées sur la configuration et l'utilisation du saut de file d'attente de WLM requêtes dans Amazon Redshift.

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.

WLMdépassement de la file d'attente

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

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 :

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 à un saut avant WLM expiration :

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 :

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ésume le comportement de différents types de requêtes avec une action de QMR saut.

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 :

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.