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.

# Didacticiel : Configuration des files d'attente de gestion manuelle de la charge de travail
<a name="tutorial-configuring-workload-management"></a>

Avec Amazon Redshift, vous pouvez configurer des files d’attente de gestion manuelle de la charge de travail (WLM) afin de hiérarchiser et d’allouer des ressources pour différents types de requêtes et d’utilisateurs. Les files d’attente de gestion manuelle de la charge de travail vous permettent de contrôler les paramètres de mémoire et de simultanéité pour des files d’attente spécifiques, afin de garantir que les charges de travail critiques reçoivent les ressources nécessaires tout en empêchant les requêtes de faible priorité de monopoliser le système. Les sections suivantes vous guident tout au long du processus de création et de configuration de files d’attente de gestion manuelle de la charge de travail dans Amazon Redshift afin de répondre à vos exigences en matière de gestion de charge de travail. 

## Présentation de
<a name="tutorial-wlm-overview"></a>

Nous recommandons de configurer la gestion automatique des charges de travail (WLM) dans Amazon Redshift. Pour de plus amples informations sur la gestion automatique de la charge de travail, veuillez consulter [Gestion de la charge de travail](cm-c-implementing-workload-management.md). Toutefois, si vous avez besoin de plusieurs files d'attente WLM, ce tutoriel vous guide à travers le processus de configuration de la gestion manuelle des charges de travail (WLM) dans Amazon Redshift. Cette configuration vous permet d'améliorer les performances des requêtes et l'allocation des ressources dans votre cluster.

Amazon Redshift achemine les requêtes des utilisateurs vers les files d'attente en vue de leur traitement. WLM définit la façon dont ces requêtes sont acheminées vers les files d'attente. Par défaut, Amazon Redshift possède deux files d'attente disponibles pour les requêtes : une pour les superutilisateurs et une pour les utilisateurs. La file d'attente des super-utilisateurs ne peut pas être configurée et ne peut traiter qu'une requête à la fois. Vous devez réserver cette file d'attente à des fins de dépannage uniquement. La file d'attente des utilisateurs peut traiter jusqu'à cinq requêtes à la fois, mais vous pouvez configurer ce nombre en modifiant le niveau de concurrence de la file d'attente si nécessaire. 

Lorsque vous avez plusieurs utilisateurs exécutant des requêtes sur la base de données, vous pouvez considérer une autre configuration comme étant plus efficace. Par exemple, si certains utilisateurs exécutent des opérations gourmandes en ressources, telles que VACUUM, celles-ci peuvent avoir un impact négatif sur les requêtes moins gourmandes, telles que les rapports. Vous pouvez envisager d'ajouter des files d'attente supplémentaires et de les configurer pour différentes charges de travail. 

**Durée estimée :** 75 minutes

**Coût estimé :** 50 cents

### Conditions préalables
<a name="tutorial-wlm-prereq"></a>

Vous avez besoin d'un cluster Amazon Redshift, de l'exemple de base de données TICKIT et de l'outil client Amazon Redshift RSQL. Si vous ne les avez pas encore installés, consultez [Guide de démarrage d'Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/gsg/new-user.html) et [Amazon Redshift RSQL](https://docs.aws.amazon.com/redshift/latest/mgmt/rsql-query-tool.html). 

### Sections
<a name="tutorial-wlm-steps"></a>
+ [Section 1 : Comprendre le comportement de traitement de file d'attente par défaut](#tutorial-wlm-understanding-default-processing)
+ [Section 2 : Modification de la configuration de la file d'attente des requêtes WLM](#tutorial-wlm-modifying-wlm-configuration)
+ [Section 3 : Acheminement des requêtes vers les files d'attente en fonction des groupes d'utilisateurs et des groupes de requêtes](#tutorial-wlm-routing-queries-to-queues)
+ [Section 4 : Utilisation de wlm\$1query\$1slot\$1count pour remplacer temporairement le niveau de concurrence d'une file d'attente](#tutorial-wlm-query-slot-count)
+ [Section 5 : Nettoyage de vos ressources](#tutorial-wlm-cleaning-up-resources)

## Section 1 : Comprendre le comportement de traitement de file d'attente par défaut
<a name="tutorial-wlm-understanding-default-processing"></a>

Avant de commencer à configurer le WLM manuel, il est utile de comprendre le comportement par défaut du traitement des files d'attente dans Amazon Redshift. Dans cette section, vous créez deux vues de base de données qui retournent des informations à partir de plusieurs tables système. Ensuite, vous exécutez quelques requêtes de test pour voir comment elles sont routées par défaut. Pour plus d’informations sur les tables système, consultez [Informations de référence sur les tables et les vues système](cm_chap_system-tables.md). 

### Étape 1 : Créer la vue WLM\$1QUEUE\$1STATE\$1VW
<a name="tutorial-wlm-create-queue-state-view"></a>

Dans cette étape, vous créez une vue appelée WLM\$1QUEUE\$1STATE\$1VW. Cette vue retourne des informations à partir des tables système suivantes.
+ [STV\$1WLM\$1CLASSIFICATION\$1CONFIG](r_STV_WLM_CLASSIFICATION_CONFIG.md)
+ [STV\$1WLM\$1SERVICE\$1CLASS\$1CONFIG](r_STV_WLM_SERVICE_CLASS_CONFIG.md)
+ [STV\$1WLM\$1SERVICE\$1CLASS\$1STATE](r_STV_WLM_SERVICE_CLASS_STATE.md)

Vous utilisez cette vue tout au long du didacticiel pour surveiller ce qu'il advient des files d'attente, une fois que vous avez modifié la configuration de la gestion de la charge de travail. Le tableau suivante décrit les données que retourne la vue WLM\$1QUEUE\$1STATE\$1VW. 

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/redshift/latest/dg/tutorial-configuring-workload-management.html)

#### Pour créer la vue WLM\$1QUEUE\$1STATE\$1VW
<a name="how-to-wlm-create-queue-state-view"></a>

1. Ouvrez [Amazon Redshift RSQL](https://docs.aws.amazon.com/redshift/latest/mgmt/rsql-query-tool.html) et connectez-vous à votre exemple de base de données TICKIT. Si vous n'avez pas cette base de données, consultez [Conditions préalables](#tutorial-wlm-prereq).

1. Exécutez la requête suivante pour créer la vue WLM\$1QUEUE\$1STATE\$1VW.

   ```
   create view WLM_QUEUE_STATE_VW as
   select (config.service_class-5) as queue
   , trim (class.condition) as description
   , config.num_query_tasks as slots
   , config.query_working_mem as mem
   , config.max_execution_time as max_time
   , config.user_group_wild_card as "user_*"
   , config.query_group_wild_card as "query_*"
   , state.num_queued_queries queued
   , state.num_executing_queries executing
   , state.num_executed_queries executed
   from
   STV_WLM_CLASSIFICATION_CONFIG class,
   STV_WLM_SERVICE_CLASS_CONFIG config,
   STV_WLM_SERVICE_CLASS_STATE state
   where
   class.action_service_class = config.service_class 
   and class.action_service_class = state.service_class 
   and config.service_class > 4
   order by config.service_class;
   ```

1. Exécutez la requête suivante pour afficher les informations que la vue contient.

   ```
   select * from wlm_queue_state_vw;
   ```

   Voici un exemple de résultat.

   ```
   query | description                               | slots | mem | max_time | user_* | query_* | queued | executing | executed
   ------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+----------
       0 | (super user) and (query group: superuser) |     1 | 357 |        0 |  false | false   |      0 |         0 |        0
       1 | (querytype:any)                           |     5 | 836 |        0 |  false | false   |      0 |         1 |      160
   ```

### Étape 2 : Créer la vue WLM\$1QUEUE\$1STATE\$1VW
<a name="tutorial-wlm-create-query-state-view"></a>

Dans cette étape, vous créez une vue appelée WLM\$1QUERY\$1STATE\$1VW. Cette vue retourne des informations à partir de la table système [STV\$1WLM\$1QUERY\$1STATE](r_STV_WLM_QUERY_STATE.md).

Vous utilisez cette vue tout au long du didacticiel pour surveiller les requêtes en cours d'exécution. Le tableau suivant décrit les données que retourne la vue WLM\$1QUERY\$1STATE\$1VW.

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/redshift/latest/dg/tutorial-configuring-workload-management.html)

#### Pour créer la vue WLM\$1QUERY\$1STATE\$1VW
<a name="how-to-wlm-create-query-state-view"></a>

1. Dans RSQL, exécutez la requête suivante pour créer la vue WLM\$1QUERY\$1STATE\$1VW.

   ```
   create view WLM_QUERY_STATE_VW as
   select query, (service_class-5) as queue, slot_count, trim(wlm_start_time) as start_time, trim(state) as state, trim(queue_time) as queue_time, trim(exec_time) as exec_time
   from stv_wlm_query_state;
   ```

1. Exécutez la requête suivante pour afficher les informations que la vue contient.

   ```
   select * from wlm_query_state_vw;
   ```

   Voici un exemple de résultat.

   ```
   query | queue | slot_count | start_time          | state     | queue_time | exec_time
   ------+-------+------------+---------------------+-----------+------------+-----------
    1249 |     1 |          1 | 2014-09-24 22:19:16 | Executing | 0          | 516
   ```

### Étape 3 : Exécuter les requêtes de test
<a name="tutorial-wlm-run-test-queries"></a>

Dans cette étape, vous exécutez des requêtes à partir de plusieurs connexions dans RSQL et examinez les tables système pour déterminer comment les requêtes ont été routées pour le traitement. 

Pour cette étape, vous avez besoin d'avoir deux fenêtres RSQL ouvertes : 
+ Dans la première fenêtre RSQL, vous exécutez des requêtes qui surveillent l'état des files d'attente et des requêtes utilisant les vues que vous avez déjà créées dans ce didacticiel.
+ Dans la deuxième fenêtre, vous exécutez des requêtes de longue durée pour modifier les résultats que vous trouvez dans la première fenêtre RSQL.

#### Pour exécuter les requêtes de test
<a name="how-to-wlm-run-test-queries"></a>

1. Ouvrez deux fenêtres RSQL. Si vous avez déjà une fenêtre ouverte, il vous suffit d'en ouvrir une seconde. Vous pouvez choisir le même compte utilisateur pour ces deux connexions.

1. Dans la première fenêtre RSQL, exécutez la requête suivante.

   ```
   select * from wlm_query_state_vw;
   ```

   Voici un exemple de résultat.

   ```
   query | queue | slot_count | start_time          | state     | queue_time | exec_time
   ------+-------+------------+---------------------+-----------+------------+-----------
    1258 |     1 |          1 | 2014-09-24 22:21:03 | Executing | 0          | 549
   ```

   Cette requête retourne un résultat faisant référence à elle-même. La requête en cours d'exécution est l'instruction SELECT de cette vue. Une requête sur cette vue retourne toujours au moins un résultat. Comparez ce résultat à celui obtenu après le démarrage de la requête de longue durée à l'étape suivante.

1. Dans la deuxième fenêtre RSQL, exécutez une requête à partir de l'exemple de base de données TICKIT. Cette requête doit s'exécuter pendant une minute environ de telle sorte que vous ayez le temps d'explorer les résultats de la vue WLM\$1QUEUE\$1STATE\$1VW et de la vue WLM\$1QUERY\$1STATE\$1VW que vous avez créées précédemment. Dans certains cas, vous pouvez constater que la requête ne s'exécute pas assez longtemps pour que vous puissiez interroger les deux vues. Dans ces cas, vous pouvez augmenter la valeur du filtre sur `l.listid ` pour qu'elle s'exécute plus longtemps.
**Note**  
Pour raccourcir le temps d'exécution des requêtes et améliorer les performances du système, Amazon Redshift met en cache le résultat de certains types de requêtes dans la mémoire du nœud principal. Lorsque la mise en cache des résultats est activée, les requêtes ultérieures s'exécutent beaucoup plus rapidement. Pour empêcher une exécution trop rapide de la requête, désactivez la mise en cache des résultats pour la séance en cours.

   Pour désactiver la mise en cache du résultat sur la séance en cours, définissez le paramètre [enable\$1result\$1cache\$1for\$1session](r_enable_result_cache_for_session.md) sur `off`, comme illustré ci-après.

   ```
   set enable_result_cache_for_session to off;
   ```

   Dans la deuxième fenêtre RSQL, exécutez la requête suivante.

   ```
   select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid < 100000;
   ```

1. Dans la première fenêtre RSQL, interrogez WLM\$1QUEUE\$1STATE\$1VW et WLM\$1QUERY\$1STATE\$1VW, puis comparez les résultats aux résultats précédents.

   ```
   select * from wlm_queue_state_vw;
   select * from wlm_query_state_vw;
   ```

   Voici quelques exemples de résultats.

   ```
   query | description                               | slots | mem | max_time | user_* | query_* | queued | executing | executed
   ------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+----------
       0 | (super user) and (query group: superuser) |     1 | 357 |        0 |  false | false   |      0 |         0 |        0
       1 | (querytype:any)                           |     5 | 836 |        0 |  false | false   |      0 |         2 |      163
                           
   query | queue | slot_count | start_time          | state     | queue_time | exec_time
   ------+-------+------------+---------------------+-----------+------------+-----------
    1267 |     1 |          1 | 2014-09-24 22:22:30 | Executing | 0          | 684
    1265 |     1 |          1 | 2014-09-24 22:22:36 | Executing | 0          | 4080859
   ```

Notez les différences suivantes entre vos requêtes précédentes et les résultats de cette étape :
+ Il y a deux lignes maintenant dans WLM\$1QUERY\$1STATE\$1VW. Un résultat est la requête faisant référence à elle-même pour exécuter une opération SELECT sur cette vue. Le deuxième résultat est la longue requête de l'étape précédente.
+ La colonne en cours d'exécution de WLM\$1QUEUE\$1STATE\$1VW a augmenté de 1 à 2. Cette entrée de colonne signifie qu'il y a deux requêtes en cours d'exécution dans la file d'attente.
+ La colonne exécutée est augmentée chaque fois que vous exécutez une requête dans la file d'attente.

La vue WLM\$1QUEUE\$1STATE\$1VW est utile pour obtenir une vue d'ensemble des files d'attente et connaître le nombre de requêtes traitées dans chaque file d'attente. La vue WLM\$1QUERY\$1STATE\$1VW est utile pour obtenir une vue plus détaillée des requêtes individuelles en cours d'exécution.

## Section 2 : Modification de la configuration de la file d'attente des requêtes WLM
<a name="tutorial-wlm-modifying-wlm-configuration"></a>

Maintenant que vous connaissez le fonctionnement par défaut des files d'attente, vous pouvez apprendre à configurer les files d'attente de requêtes à l'aide de la gestion manuelle de la charge de travail. Dans cette section, vous créez et configurez un nouveau groupe de paramètres pour votre cluster. Vous créez deux files d'attente d'utilisateurs supplémentaires et les configurez pour accepter les requêtes basées sur le groupe d'utilisateurs des requêtes ou sur les étiquettes de groupe de requêtes. Toute requête qui n'est pas routée vers l'une de ces deux files d'attente est routée vers la file d'attente par défaut au moment de l'exécution.

**Pour créer configuration WLM manuelle dans un groupe de paramètres**

1. Connectez-vous à la console Amazon Redshift AWS Management Console et ouvrez-la à l'adresse. [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/)

1. Dans le menu de navigation, choisissez **Configurations**, puis choisissez **Gestion des charges de travail** pour afficher la page **Gestion des charges de travail**. 

1. Choisissez **Créer** pour afficher la fenêtre **Créer un groupe de paramètres**. 

1. Saisissez **WLMTutorial** pour le **Nom du groupe de paramètres** et la **Description**, puis choisissez **Créer** pour créer le groupe de paramètres. 
**Note**  
Le **Nom du groupe de paramètres** est converti au format minuscules pour toutes les lettres lors de sa création. 

1. Sur la page **Gestion des charges de travail**, choisissez le groupe de paramètres **wlmtutorial** pour afficher la page des détails avec des onglets pour **Paramètres** et **Gestion des charges de travail**. 

1. Vérifiez que vous êtes sur l'onglet **Gestion des charges de travail**, puis choisissez **Passer en mode WLM** pour afficher la fenêtre **Paramètres de simultanéité**. 

1. Choisissez **WLM manuel**, puis **Enregistrer** pour passer à WLM manuel. 

1. Choisissez **Modifier les files d'attente de charge de travail**. 

1. Choisissez **Ajouter une file d'attente** deux fois pour ajouter deux files d'attente. Il y a désormais trois files d'attente : **File d'attente 1**, **File d'attente 2** et **File d'attente**. 

1. Entrez les informations de chaque file d'attente de la façon suivante : 
   + Pour **File d'attente 1**, entrez **30** pour **Mémoire (%)**, **2** pour **Simultanéité sur principal** et **test** pour **Groupes de requêtes**. Conservez les valeurs par défaut des autres paramètres.
   + Pour **File d'attente 2**, entrez **40** pour **Mémoire (%)**, **3** pour **Simultanéité sur principal** et **admin** pour **Groupes d'utilisateurs**. Conservez les valeurs par défaut des autres paramètres.
   + Définissez la valeur **Simultanéité sur principal** pour la file d’attente par défaut sur une valeur supérieure ou égale à 1. N’apportez aucune autre modification à la **File d’attente par défaut**. La gestion de la charge de travail affecte la mémoire non allouée à la file d'attente par défaut. 

1. Choisissez **Save (Enregistrer)** pour enregistrer vos paramètres. 

Ensuite, associez à un cluster le groupe de paramètres avec la configuration WLM manuelle.

**Pour associer à un cluster un groupe de paramètres à une configuration WLM manuelle**

1. Connectez-vous à la console Amazon Redshift AWS Management Console et ouvrez-la à l'adresse. [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/)

1. Dans le menu de navigation, choisissez **Clusters**, puis choisissez **Clusters** pour afficher la liste des clusters. 

1. Choisissez votre cluster, par exemple `examplecluster`, pour afficher les informations du cluster. Sélectionnez ensuite l'option **Propriétés** pour afficher les propriétés de ce cluster. 

1. Dans la section **Configurations de base de données**, sélectionnez **Modifier**, puis **Modifier le groupe de paramètres** pour afficher la fenêtre Groupes de paramètres. 

1. Pour **Groupes de paramètres**, sélectionnez le groupe de paramètres **wlmtutorial** que vous avez précédemment créé. 

1. Sélectionnez **Enregistrer les modifications** pour associer le groupe de paramètres. 

   Le cluster est modifié avec le groupe de paramètres modifié. Toutefois, vous devez redémarrer le cluster pour que les modifications soient également appliquées à la base de données.

1. Choisissez votre cluster, puis choisissez **Redémarrer le cluster** comme **Actions**. 

Une fois que le cluster a été redémarré, le statut redevient **Disponible**. 

## Section 3 : Acheminement des requêtes vers les files d'attente en fonction des groupes d'utilisateurs et des groupes de requêtes
<a name="tutorial-wlm-routing-queries-to-queues"></a>

À présent votre cluster est associé à un nouveau groupe de paramètres et vous avez configuré la gestion de la charge de travail. Ensuite, exécutez quelques requêtes pour voir comment Amazon Redshift achemine les requêtes dans les files d'attente pour le traitement.

### Étape 1 : Afficher la configuration de la file d'attente de requêtes dans la base de données
<a name="tutorial-wlm-view-query-config"></a>

D'abord, vérifiez que la base de données possède la configuration WLM que vous attendez.

#### Pour afficher la configuration de la file d'attente de requêtes
<a name="how-to-wlm-view-query-config"></a>

1. Ouvrez RSQL et exécutez la requête suivante. La requête utilise la vue WLM\$1QUEUE\$1STATE\$1VW que vous avez créée dans [Étape 1 : Créer la vue WLM\$1QUEUE\$1STATE\$1VW](#tutorial-wlm-create-queue-state-view). Si vous aviez déjà une séance connectée à la base de données avant le redémarrage du cluster, vous devez vous reconnecter.

   ```
   select * from wlm_queue_state_vw;
   ```

   Voici un exemple de résultat.

   ```
   query | description                               | slots | mem | max_time | user_* | query_* | queued | executing | executed
   ------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+----------
       0 | (super user) and (query group: superuser) |     1 | 357 |        0 |  false | false   |      0 |         0 |        0
       1 | (query group: test)                       |     2 | 627 |        0 |  false | false   |      0 |         0 |        0
       2 | (suser group: admin)                      |     3 | 557 |        0 |  false | false   |      0 |         0 |        0
       3 | (querytype:any)                           |     5 | 250 |        0 |  false | false   |      0 |         1 |        0
   ```

   Comparer ces résultats à ceux que vous avez reçus dans [Étape 1 : Créer la vue WLM\$1QUEUE\$1STATE\$1VW](#tutorial-wlm-create-queue-state-view). Notez qu'il y a désormais deux files d'attente supplémentaires. Queue 1 est maintenant la file d'attente du groupe de requêtes de test et Queue 2 la file d'attente du groupe utilisateur administrateur.

   Queue 3 est maintenant la file d'attente par défaut. La dernière file d'attente de la liste est toujours la file d'attente par défaut. Elle correspond à la file d'attente vers laquelle les requêtes sont routées par défaut si aucun groupe d'utilisateurs ni groupe de requêtes n'est spécifié dans une requête.

1. Exécutez la requête suivante pour confirmer que votre requête s'exécute maintenant dans la file d'attente 3.

   ```
   select * from wlm_query_state_vw;
   ```

   Voici un exemple de résultat.

   ```
   query | queue | slot_count | start_time          | state     | queue_time | exec_time
   ------+-------+------------+---------------------+-----------+------------+-----------
    2144 |     3 |          1 | 2014-09-24 23:49:59 | Executing | 0          | 550430
   ```

### Étape 2 : Exécuter une requête à l'aide de la file d'attente du groupe de requêtes
<a name="tutorial-wlm-query-group"></a>

#### Pour exécuter une requête à l'aide de la file d'attente du groupe de requêtes
<a name="how-to-wlm-query-group"></a>

1. Exécutez la requête suivante pour l'acheminer vers le groupe de requêtes `test`.

   ```
   set query_group to test;
   select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000;
   ```

1. Dans l'autre fenêtre RSQL, exécutez la requête suivante.

   ```
   select * from wlm_query_state_vw;
   ```

   Voici un exemple de résultat.

   ```
   query | queue | slot_count | start_time          | state     | queue_time | exec_time
   ------+-------+------------+---------------------+-----------+------------+-----------
    2168 |     1 |          1 | 2014-09-24 23:54:18 | Executing | 0          | 6343309
    2170 |     3 |          1 | 2014-09-24 23:54:24 | Executing | 0          | 847
   ```

   La requête a été acheminée vers le groupe de requêtes de test, à savoir queue 1 maintenant.

1. Sélectionnez tout à partir de la vue d'état de la file d'attente.

   ```
   select * from wlm_queue_state_vw;
   ```

   Vous voyez un résultat similaire au suivant.

   ```
   query | description                               | slots | mem | max_time | user_* | query_* | queued | executing | executed
   ------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+----------
       0 | (super user) and (query group: superuser) |     1 | 357 |        0 |  false | false   |      0 |         0 |        0
       1 | (query group: test)                       |     2 | 627 |        0 |  false | false   |      0 |         1 |        0
       2 | (suser group: admin)                      |     3 | 557 |        0 |  false | false   |      0 |         0 |        0
       3 | (querytype:any)                           |     5 | 250 |        0 |  false | false   |      0 |         1 |        0
   ```

1. Maintenant, réinitialisez le groupe de requêtes et exécutez la longue requête à nouveau :

   ```
   reset query_group;
   select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000;
   ```

1. Exécutez les requêtes sur les vues pour afficher les résultats.

   ```
   select * from wlm_queue_state_vw;
   select * from wlm_query_state_vw;
   ```

   Voici quelques exemples de résultats.

   ```
   query | description                               | slots | mem | max_time | user_* | query_* | queued | executing | executed
   ------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+----------
       0 | (super user) and (query group: superuser) |     1 | 357 |        0 |  false | false   |      0 |         0 |        0
       1 | (query group: test)                       |     2 | 627 |        0 |  false | false   |      0 |         0 |        1
       2 | (suser group: admin)                      |     3 | 557 |        0 |  false | false   |      0 |         0 |        0
       3 | (querytype:any)                           |     5 | 250 |        0 |  false | false   |      0 |         2 |        5
    
   query | queue | slot_count | start_time          | state     | queue_time | exec_time
   ------+-------+------------+---------------------+-----------+------------+-----------
    2186 |     3 |          1 | 2014-09-24 23:57:52 | Executing | 0          | 649
    2184 |     3 |          1 | 2014-09-24 23:57:48 | Executing | 0          | 4137349
   ```

   Le résultat doit être que la requête s'exécute maintenant dans la file d'attente 3 à nouveau.

### Étape 3 : Créer un utilisateur de base de données et un groupe
<a name="tutorial-wlm-create-db-user-and-group"></a>

Avant de pouvoir exécuter des requêtes dans cette file d'attente, vous devez créer le groupe d'utilisateurs dans la base de données et ajouter un utilisateur au groupe. Ensuite, vous vous connectez avec RSQL à l'aide des informations d'identification du nouvel utilisateur et exécutez les requêtes. Vous avez besoin d'exécuter des requêtes comme super-utilisateur, tel qu'utilisateur administrateur, pour pouvoir créer des utilisateurs de base de données.

#### Pour créer un utilisateur de base de données et un groupe d'utilisateurs
<a name="how-to-wlm-create-db-user-and-group"></a>

1. Dans la base de données, créez un utilisateur de base de données nommé `adminwlm` en exécutant la commande suivante dans une fenêtre RSQL.

   ```
   create user adminwlm createuser password '123Admin';
   ```

1. Puis, exécutez les commandes suivantes pour créer le nouveau groupe d'utilisateurs et lui ajouter votre nouvel utilisateur `adminwlm`.

   ```
   create group admin;
   alter group admin add user adminwlm;
   ```

### Étape 4 : Exécuter une requête à l'aide de la file d'attente du groupe d'utilisateurs
<a name="tutorial-wlm-user-group-query"></a>

Ensuite, vous exécutez une requête et la routez vers la file d'attente du groupe d'utilisateurs. Vous procédez ainsi lorsque vous souhaitez acheminer votre requête vers une file d'attente configurée pour gérer le type de requête que vous souhaitez exécuter.

#### Pour exécuter une requête à l'aide de la file d'attente du groupe d'utilisateurs
<a name="how-to-wlm-user-group-query"></a>

1. Dans la deuxième fenêtre RSQL, exécutez les requêtes suivantes pour basculer vers le compte `adminwlm` et exécuter une requête en tant qu'utilisateur.

   ```
   set session authorization 'adminwlm';
   select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000;
   ```

1. Dans la première fenêtre RSQL, exécutez la requête suivante pour voir vers quelle file d'attente les requêtes sont acheminées.

   ```
   select * from wlm_query_state_vw;
   select * from wlm_queue_state_vw;
   ```

   Voici quelques exemples de résultats.

   ```
   query | description                               | slots | mem | max_time | user_* | query_* | queued | executing | executed
   ------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+----------
       0 | (super user) and (query group: superuser) |     1 | 357 |        0 |  false | false   |      0 |         0 |        0
       1 | (query group: test)                       |     2 | 627 |        0 |  false | false   |      0 |         0 |        1
       2 | (suser group: admin)                      |     3 | 557 |        0 |  false | false   |      0 |         1 |        0
       3 | (querytype:any)                           |     5 | 250 |        0 |  false | false   |      0 |         1 |        8
    
   query | queue | slot_count | start_time          | state     | queue_time | exec_time
   ------+-------+------------+---------------------+-----------+------------+-----------
    2202 |     2 |          1 | 2014-09-25 00:01:38 | Executing | 0          | 4885796
    2204 |     3 |          1 | 2014-09-25 00:01:43 | Executing | 0          | 650
   ```

   La file d'attente dans laquelle cette requête a été exécutée est la file d'attente 2, celle de l'utilisateur `admin`. Chaque fois que vous exécutez des requêtes en étant connecté sous l'identité de cet utilisateur, elles s'exécutent dans la file d'attente 2, sauf si vous spécifiez un autre groupe de requêtes à utiliser. La file d'attente choisie dépend des règles d'affectation de file d'attente. Pour plus d’informations, consultez [Règles d’affectation de file d’attente de WLM](cm-c-wlm-queue-assignment-rules.md). 

1. Maintenant, exécutez la requête suivante à partir de la deuxième fenêtre RSQL.

   ```
   set query_group to test;
   select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000;
   ```

1. Dans la première fenêtre RSQL, exécutez la requête suivante pour voir vers quelle file d'attente les requêtes sont acheminées.

   ```
   select * from wlm_queue_state_vw;
   select * from wlm_query_state_vw;
   ```

   Voici quelques exemples de résultats.

   ```
   query | description                               | slots | mem | max_time | user_* | query_* | queued | executing | executed
   ------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+----------
       0 | (super user) and (query group: superuser) |     1 | 357 |        0 |  false | false   |      0 |         0 |        0
       1 | (query group: test)                       |     2 | 627 |        0 |  false | false   |      0 |         1 |        1
       2 | (suser group: admin)                      |     3 | 557 |        0 |  false | false   |      0 |         0 |        1
       3 | (querytype:any)                           |     5 | 250 |        0 |  false | false   |      0 |         1 |       10
    
   query | queue | slot_count | start_time          | state     | queue_time | exec_time
   ------+-------+------------+---------------------+-----------+------------+-----------
    2218 |     1 |          1 | 2014-09-25 00:04:30 | Executing | 0          | 4819666
    2220 |     3 |          1 | 2014-09-25 00:04:35 | Executing | 0          | 685
   ```

1. Lorsque vous avez terminé, réinitialisez le groupe de requêtes.

   ```
   reset query_group;
   ```

## Section 4 : Utilisation de wlm\$1query\$1slot\$1count pour remplacer temporairement le niveau de concurrence d'une file d'attente
<a name="tutorial-wlm-query-slot-count"></a>

Parfois, les utilisateurs peuvent avoir temporairement besoin de plus de ressources pour une requête donnée. Si tel est le cas, ils peuvent utiliser le paramètre de configuration wlm\$1query\$1slot\$1count pour remplacer temporairement la manière dont les emplacements sont alloués dans une file d'attente de requêtes. Les *emplacements* correspondent aux unités de mémoire et à l'UC utilisées pour traiter les requêtes. Vous pouvez remplacer le nombre d'emplacements lorsque vous avez des requêtes occasionnelles qui nécessitent un grand nombre de ressources dans le cluster, comme lorsque vous effectuez une opération VACUUM dans la base de données. 

Vous constatez peut-être que les utilisateurs ont souvent besoin de définir wlm\$1query\$1slot\$1count pour certains types de requêtes. Si tel est le cas, envisagez d'ajuster la configuration de la gestion de la charge de travail et de proposer aux utilisateurs une file d'attente mieux adaptée aux besoins de leurs requêtes. Pour de plus amples informations sur la substitution temporaire du niveau de concurrence à l'aide du nombre d'emplacements, veuillez consultez [wlm\$1query\$1slot\$1count](r_wlm_query_slot_count.md).

### Étape 1 : Remplacer le niveau de concurrence à l'aide de wlm\$1query\$1slot\$1count
<a name="tutorial-wlm-override-slot-count"></a>

Dans le cadre de ce didacticiel, nous exécutons la même requête SELECT de longue durée. Nous l'exécutons sous l'identité de l'utilisateur `adminwlm` en utilisant wlm\$1query\$1slot\$1count pour augmenter le nombre d'emplacements disponibles pour la requête.

#### Pour remplacer le niveau de concurrence à l'aide de wlm\$1query\$1slot\$1count
<a name="how-to-wlm-override-slot-count"></a>

1. Augmentez la limite de la requête pour vous assurer que vous avez assez de temps pour interroger la vue WLM\$1QUERY\$1STATE\$1VW et afficher un résultat. 

   ```
   set wlm_query_slot_count to 3; 
   select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000;
   ```

1. Maintenant, interrogez WLM\$1QUERY\$1STATE\$1VW avec l'utilisateur administrateur pour voir comment la requête s'exécute.

   ```
   select * from wlm_query_state_vw;
   ```

   Voici un exemple de résultat.

   ```
   query | queue | slot_count | start_time          | state     | queue_time | exec_time
   ------+-------+------------+---------------------+-----------+------------+-----------
    2240 |     2 |          1 | 2014-09-25 00:08:45 | Executing | 0          | 3731414
    2242 |     3 |          1 | 2014-09-25 00:08:49 | Executing | 0          | 596
   ```

   Notez que le nombre d'emplacements pour la requête est 3. Ce nombre signifie que la requête utilise les trois emplacements pour traiter la requête et alloue la totalité des ressources de la file d'attente à cette requête.

1. Maintenant, exécutez la requête suivante.

   ```
   select * from WLM_QUEUE_STATE_VW;
   ```

   Voici un exemple de résultat.

   ```
   query | description                               | slots | mem | max_time | user_* | query_* | queued | executing | executed
   ------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+----------
       0 | (super user) and (query group: superuser) |     1 | 357 |        0 |  false | false   |      0 |         0 |        0
       1 | (query group: test)                       |     2 | 627 |        0 |  false | false   |      0 |         0 |        4
       2 | (suser group: admin)                      |     3 | 557 |        0 |  false | false   |      0 |         1 |        3
       3 | (querytype:any)                           |     5 | 250 |        0 |  false | false   |      0 |         1 |       25
   ```

   Le paramètre de configuration wlm\$1query\$1slot\$1count est valide pour la séance en cours uniquement. Si cette séance expire ou qu'un autre utilisateur exécute une requête, la configuration WLM est utilisée.

1. Réinitialisez le nombre d'emplacements et exécutez à nouveau le test.

   ```
   reset wlm_query_slot_count;
   select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000;
   ```

   Voici quelques exemples de résultats.

   ```
   query | description                               | slots | mem | max_time | user_* | query_* | queued | executing | executed
   ------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+----------
       0 | (super user) and (query group: superuser) |     1 | 357 |        0 |  false | false   |      0 |         0 |        0
       1 | (query group: test)                       |     2 | 627 |        0 |  false | false   |      0 |         0 |        2
       2 | (suser group: admin)                      |     3 | 557 |        0 |  false | false   |      0 |         1 |        2
       3 | (querytype:any)                           |     5 | 250 |        0 |  false | false   |      0 |         1 |       14
    
   query | queue | slot_count | start_time          | state     | queue_time | exec_time
   ------+-------+------------+---------------------+-----------+------------+-----------
    2260 |     2 |          1 | 2014-09-25 00:12:11 | Executing | 0          | 4042618
    2262 |     3 |          1 | 2014-09-25 00:12:15 | Executing | 0          | 680
   ```

### Étape 2 : Exécuter les requêtes à partir de différentes séances
<a name="tutorial-wlm-run-queries-from-different-sessions"></a>

Ensuite, exécutez les requêtes à partir de différentes séances.

#### Pour exécuter les requêtes à partir de différentes séances
<a name="how-to-wlm-run-queries-from-different-sessions"></a>

1. Dans les première et deuxième fenêtres RSQL, exécutez la commande suivante pour utiliser le groupe de requêtes de test.

   ```
   set query_group to test;
   ```

1. Dans la première fenêtre RSQL, exécutez la longue requête suivante.

   ```
   select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000;
   ```

1. Pendant que la requête de longue durée s'exécute dans la première fenêtre RSQL, exécutez les commandes suivantes. Elles augmentent le nombre d'emplacements pour utiliser tous les emplacements pour la file d'attente, puis commencent à exécuter la requête de longue durée.

   ```
   set wlm_query_slot_count to 2;
   select avg(l.priceperticket*s.qtysold) from listing l, sales s where l.listid <40000;
   ```

1. Ouvrez une troisième fenêtre RSQL et interrogez les vues pour afficher les résultats.

   ```
   select * from wlm_queue_state_vw;
   select * from wlm_query_state_vw;
   ```

   Voici quelques exemples de résultats.

   ```
   query | description                               | slots | mem | max_time | user_* | query_* | queued | executing | executed
   ------+-------------------------------------------+-------+-----+----------+--------+---------+--------+-----------+----------
       0 | (super user) and (query group: superuser) |     1 | 357 |        0 |  false | false   |      0 |         0 |        0
       1 | (query group: test)                       |     2 | 627 |        0 |  false | false   |      1 |         1 |        2
       2 | (suser group: admin)                      |     3 | 557 |        0 |  false | false   |      0 |         0 |        3
       3 | (querytype:any)                           |     5 | 250 |        0 |  false | false   |      0 |         1 |       18
    
   query | queue | slot_count | start_time          | state         | queue_time | exec_time
   ------+-------+------------+---------------------+---------------+------------+-----------
    2286 |     1 |          2 | 2014-09-25 00:16:48 | QueuedWaiting | 3758950    | 0
    2282 |     1 |          1 | 2014-09-25 00:16:33 | Executing     | 0          | 19335850
    2288 |     3 |          1 | 2014-09-25 00:16:52 | Executing     | 0          | 666
   ```

   Notez que la première requête utilise l'un des emplacements alloués à la file d'attente 1 pour exécuter la requête. De plus, notez qu'une requête est en attente dans la file d'attente (`queued` a pour valeur `1` et `state` a pour valeur `QueuedWaiting`). Une fois la première requête terminée, la deuxième commence à s'exécuter. Cette exécution se produit parce que les deux requêtes sont acheminées vers le groupe de requêtes `test` et la deuxième requête doit attendre qu'il y ait un nombre suffisant d'emplacements pour commencer le traitement.

## Section 5 : Nettoyage de vos ressources
<a name="tutorial-wlm-cleaning-up-resources"></a>

Votre cluster continue d’accumuler les frais aussi longtemps qu’il est en cours d’exécution. Lorsque vous avez terminé ce tutoriel, remettez votre environnement dans l'état précédent en suivant les étapes des rubriques [Trouver des ressources supplémentaires et Réinitialiser votre environnement](https://docs.aws.amazon.com/redshift/latest/gsg/rs-gsg-clean-up-tasks.html) du *Guide de démarrage d'Amazon Redshift*.

Pour de plus amples informations sur la gestion de la charge de travail, veuillez consulter [Gestion de la charge de travail](cm-c-implementing-workload-management.md).