Amazon Redshift non supporterà più la creazione di nuovi Python UDFs a partire dalla Patch 198. Python esistente UDFs continuerà a funzionare fino al 30 giugno 2026. Per ulteriori informazioni, consulta il [post del blog](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/). 

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

# Tutorial: Configurazione delle code di gestione manuale del carico di lavoro (WLM)
<a name="tutorial-configuring-workload-management"></a>

Con Amazon Redshift puoi configurare le code di gestione dei carichi di lavoro (WLM) manuale per assegnare la priorità e allocare le risorse per diversi tipi di query e utenti. Le code di WLM manuale consentono di controllare la memoria e le impostazioni di simultaneità per code specifiche, facendo in modo che i carichi di lavoro critici ricevano le risorse necessarie e impedendo al contempo che le query a bassa priorità monopolizzino il sistema. Nelle sezioni seguenti viene illustrato il processo di creazione e configurazione delle code di WLM manuale in Amazon Redshift per soddisfare i requisiti di gestione dei carichi di lavoro. 

## Panoramica di
<a name="tutorial-wlm-overview"></a>

Consigliamo di configurare la gestione automatica del carico di lavoro (WLM) in Amazon Redshift. Per ulteriori informazioni sulla funzionalità WLM automatica, consultare [Gestione dei carichi di lavoro](cm-c-implementing-workload-management.md). Tuttavia, se c'è bisogno di più code WLM, questo tutorial introdurrà al processo di configurazione della gestione manuale del carico di lavoro (WLM) in Amazon Redshift. Grazie alla configurazione WLM manuale, puoi migliorare le prestazioni relative alle query e l'assegnazione delle risorse nel cluster.

Amazon Redshift instrada le query degli utenti alle code per l'elaborazione. Le modalità con cui le query devono essere instradate alle code vengono definite da WLM . Per impostazione predefinita, in Amazon Redshift sono disponibili due code per le query: una per gli utenti con privilegi avanzati e una per gli utenti. La coda dell'utente con privilegi avanzati non può essere configurata e può elaborare una sola query per volta. È consigliabile riservare questa coda solo per la risoluzione dei problemi. La coda per gli utenti può elaborare fino a cinque code per volta tuttavia, se necessario, si può modificare il livello di simultaneità della coda. 

Se più utenti eseguono query sul database, potrebbe essere più efficace una configurazione diversa. Ad esempio, se alcuni utenti eseguono operazioni che richiedono un numero elevato di risorse, come VACUUM, queste potrebbero avere un impatto negativo sulle query meno impegnative, ad esempio i report. Potresti valutare l'opportunità di aggiungere altre code e di configurarle per carichi di lavoro diversi. 

**Tempo previsto:** 75 minuti

**Costo previsto:** 50 centesimi

### Prerequisiti
<a name="tutorial-wlm-prereq"></a>

Sono necessari un cluster Amazon Redshift, il database TICKIT di esempio e lo strumento client Amazon Redshift RSQL. Se non sono ancora configurati, consulta la [Guida alle operazioni di base di Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/gsg/new-user.html) e [Amazon Redshift RSQL](https://docs.aws.amazon.com/redshift/latest/mgmt/rsql-query-tool.html). 

### Sections
<a name="tutorial-wlm-steps"></a>
+ [Sezione 1: informazioni sul comportamento predefinito di elaborazione delle code](#tutorial-wlm-understanding-default-processing)
+ [Sezione 2: modifica della configurazione delle code di query WLM](#tutorial-wlm-modifying-wlm-configuration)
+ [Sezione 3: instradamento delle query alle code in base ai gruppi di utenti e ai gruppi di query](#tutorial-wlm-routing-queries-to-queues)
+ [Sezione 4: utilizzo di wlm\$1query\$1slot\$1count per ignorare temporaneamente il livello di simultaneità in una coda](#tutorial-wlm-query-slot-count)
+ [Sezione 5: pulizia delle risorse](#tutorial-wlm-cleaning-up-resources)

## Sezione 1: informazioni sul comportamento predefinito di elaborazione delle code
<a name="tutorial-wlm-understanding-default-processing"></a>

Prima di iniziare a configurare la WLM manuale, può essere utile conoscere il comportamento di default dell'elaborazione delle code in Amazon Redshift. In questa sezione creerai due viste database che restituiscono informazioni da diverse tabelle di sistema. Quindi eseguirai alcune query di prova per vedere come vengono instradate per impostazione predefinita. Per ulteriori informazioni sulle tabelle di sistema, consultare [Riferimento di tabelle e viste di sistema](cm_chap_system-tables.md). 

### Fase 1: creazione della vista WLM\$1QUEUE\$1STATE\$1VW
<a name="tutorial-wlm-create-queue-state-view"></a>

In questa fase creerai una vista denominata WLM\$1QUEUE\$1STATE\$1VW. Questa vista restituisce informazioni dalle tabelle di sistema seguenti.
+ [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)

Utilizzerai questa vista in tutto il tutorial per monitorare ciò che accade alle code dopo avere modificato la configurazione WLM. Nella seguente tabella sono descritti i dati restituiti dalla vista WLM\$1QUEUE\$1STATE\$1VW. 

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

#### Per creare la vista WLM\$1QUEUE\$1STATE\$1VW
<a name="how-to-wlm-create-queue-state-view"></a>

1. Apri [Amazon Redshift RSQL](https://docs.aws.amazon.com/redshift/latest/mgmt/rsql-query-tool.html) e connettiti al database di esempio TICKIT. Se questo database non è presente, vedi [Prerequisiti](#tutorial-wlm-prereq).

1. Eseguire la query seguente per creare la vista 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. Eseguire la query seguente per vedere le informazioni incluse nella vista.

   ```
   select * from wlm_queue_state_vw;
   ```

   Di seguito è riportato un risultato di esempio.

   ```
   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
   ```

### Fase 2: creazione della vista WLM\$1QUERY\$1STATE\$1VW
<a name="tutorial-wlm-create-query-state-view"></a>

In questa fase creerai una vista denominata WLM\$1QUERY\$1STATE\$1VW. Questa vista restituisce informazioni dalla tabella di sistema [STV\$1WLM\$1QUERY\$1STATE](r_STV_WLM_QUERY_STATE.md).

Utilizzerai questa vista in tutto il tutorial per monitorare le query in esecuzione. Nella seguente tabella sono descritti i dati restituiti dalla vista WLM\$1QUERY\$1STATE\$1VW.

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

#### Per creare la vista WLM\$1QUERY\$1STATE\$1VW
<a name="how-to-wlm-create-query-state-view"></a>

1. In RSQL esegui la query seguente per creare la vista 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. Eseguire la query seguente per vedere le informazioni incluse nella vista.

   ```
   select * from wlm_query_state_vw;
   ```

   Di seguito è riportato un risultato di esempio.

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

### Fase 3: esecuzione delle query di test
<a name="tutorial-wlm-run-test-queries"></a>

In questa fase eseguirai query da più connessioni in RSQL ed esaminerai le tabelle di sistema per stabilire il modo in cui le query sono state instradate per l'elaborazione. 

Per questo passaggio, è necessario che siano aperte due finestre RSQL: 
+ Nella finestra RSQL 1 eseguirai le query che monitorano lo stato delle code e le query che utilizzano le viste già create in questo tutorial.
+ Nella finestra RSQL 2 eseguirai le query di lunga durata per modificare i risultati trovati nella finestra RSQL 1.

#### Per eseguire le query di test
<a name="how-to-wlm-run-test-queries"></a>

1. Apri due finestre RSQL. Se è già aperta una finestra, sarà sufficiente aprire la seconda. È possibile utilizzare lo stesso account utente per entrambe le connessioni.

1. Nella finestra RSQL 1 esegui la query seguente.

   ```
   select * from wlm_query_state_vw;
   ```

   Di seguito è riportato un risultato di esempio.

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

   Questa query restituisce un risultato autoreferenziale. La query attualmente in esecuzione è l'istruzione SELECT da questa vista. Una query su questa vista restituisce sempre almeno un risultato, che si deve confrontare con quello che si ottiene avviando la query di lunga durata al passaggio successivo.

1. Nella finestra RSQL 2 esegui una query dal database TICKIT di esempio. Questa query deve essere eseguita per circa un minuto, in modo che sia possibile esplorare i risultati della vista WLM\$1QUEUE\$1STATE\$1VW e la vista WLM\$1QUERY\$1STATE\$1VW creata precedentemente. In alcuni casi, potresti osservare che la query non viene eseguita abbastanza a lungo per interrogare entrambe le viste. In questi casi, puoi aumentare il valore del filtro su `l.listid `affinché la query venga eseguita più a lungo.
**Nota**  
Per ridurre il tempo di esecuzione delle query e migliorare le prestazioni del sistema, Amazon Redshift memorizza i risultati di certi tipi di query nella memoria cache del nodo principale. Se è abilitato il caching dei risultati, l'esecuzione delle query successive è moto più rapida. Per evitare che la query venga eseguita troppo rapidamente, è possibile disabilitare il caching dei risultati per la sessione corrente.

   Per disattivare il caching dei risultati per la sessione corrente, è possibile impostare il parametro [enable\$1result\$1cache\$1for\$1session](r_enable_result_cache_for_session.md) su `off` come mostrato di seguito.

   ```
   set enable_result_cache_for_session to off;
   ```

   Nella finestra RSQL 2 esegui la query seguente.

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

1. Nella finestra RSQL 1, esegui una query WLM\$1QUEUE\$1STATE\$1VW e WLM\$1QUERY\$1STATE\$1VW e confronta i risultati con quelli precedenti.

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

   Di seguito sono riportati i risultati di esempio.

   ```
   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
   ```

Di seguito vengono illustrate le differenze tra le query precedenti e i risultati di questa fase:
+ Ora in WLM\$1QUERY\$1STATE\$1VW sono presenti due righe. Un risultato è la query autoreferenziale per l'esecuzione di un'operazione SELECT in questa vista. Il secondo risultato è la query di lunga durata della fase precedente.
+ Il valore della colonna di esecuzione in WLM\$1QUEUE\$1STATE\$1VW è aumentato da 1 a 2. La voce di questa colonna indica che nella coda sono in esecuzione due query.
+ Il valore della colonna eseguita aumenta ogni volta che si esegue una query nella coda.

La vista WLM\$1QUEUE\$1STATE\$1VW è utile per ottenere una vista generale delle code e per conoscere il numero di query in elaborazione in ogni coda. La vista WLM\$1QUERY\$1STATE\$1VW è utile per ottenere una vista più dettagliata delle singole query attualmente in esecuzione.

## Sezione 2: modifica della configurazione delle code di query WLM
<a name="tutorial-wlm-modifying-wlm-configuration"></a>

Ora che hai compreso il funzionamento delle code, puoi imparare come configurare le code di query utilizzando WLM manuale. In questa sezione creerai e configurerai un nuovo gruppo di parametri per il tuo cluster. Creerai due code utente aggiuntive e le configurerai in modo che accettino le query in base alle etichette del gruppo di utenti o del gruppo di query. Le query che non vengono instradate a una di queste due code verranno instradate alla coda predefinita in fase di runtime.

**Per modificare la configurazione WLM in un gruppo di parametri**

1. Accedi Console di gestione AWS e apri la console Amazon Redshift all'indirizzo. [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/)

1. Dal menu di navigazione scegliere **Configurations** (Configurazioni), quindi scegliere **Workload management** (Gestione carichi di lavoro) per visualizzare la pagina **Workload management** Gestione carichi di lavoro). 

1. Scegli **Create (Crea)** per visualizzare la finestra **Create parameter group (Crea gruppo di parametri)**. 

1. Inserisci **WLMTutorial** per **Nome del gruppo di parametri** e **Descrizione**, quindi scegli **Crea** per creare il gruppo di parametri. 
**Nota**  
Il **Parameter group name (Nome del gruppo di parametri)** è trasformato in minuscolo al momento della creazione. 

1. Nella pagina **Workload management (Gestione workload)**, scegli il gruppo di parametri **wlmtutorial** per visualizzare la pagina dei dettagli con le schede **Parameters (Parametri)** e **Workload management (Gestione workload)**. 

1. Verificare di trovarti nella scheda **Gestione del carico di lavoro**, quindi scegliere **Modifica modalità WLM** per visualizzare la finestra **Impostazioni simultaneità**. 

1. Scegli **Manual WLM (WLM manuale)**, quindi scegli **Save (Salva)** per passare al WLM manuale. 

1. Scegli **Edit workload queues (Modifica code di workload)**. 

1. Scegli **Add queue (Aggiungi coda)** due volte per aggiungere due code. Ora sono presenti tre code: **Queue 1 (Coda 1)**, **Queue 2 (Coda 2)** e **Default queue (Coda predefinita)**. 

1. Inserisci le informazioni per ogni coda come segue: 
   + Per **Coda 1**, inserire **30** alla voce **Memoria (%)**, **2** alla voce **Simultaneità su principale** e **test** alla voce **Gruppi di query**. Lascia le altre impostazioni con i valori predefiniti.
   + Per **Coda 2**, inserire **40** alla voce **Memoria (%)**, **3** alla voce **Simultaneità su principale**e **admin** alla voce **Gruppi di utenti**. Lascia le altre impostazioni con i valori predefiniti.
   + Imposta il valore **Simultaneità su principale** per la coda predefinita su un valore superiore o uguale a 1. Non apportare alcuna modifica alla **Coda predefinita**. WLM assegna memoria non allocata alla coda predefinita. 

1. Per salvare le impostazioni, scegli **Save (Salva)**. 

Quindi, associa il gruppo di parametri che ha la configurazione WLM manuale a un cluster.

**Associare un gruppo di parametri con configurazione WLM manuale a un cluster**

1. Accedi Console di gestione AWS e apri la console Amazon Redshift all'indirizzo. [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/)

1. Dal menu di navigazione, scegliere **Clusters** (Cluster), quindi scegliere **Clusters** (Cluster) per visualizzare un elenco dei cluster. 

1. Selezionare il cluster, come `examplecluster` per visualizzarne i dettagli. Quindi scegliere la scheda **Proprietà** per visualizzare le proprietà del cluster. 

1. Nella sezione **Configurazioni del database**, scegliere **Modifica**, **Modifica il gruppo di parametri** per visualizzare la finestra dei gruppi di parametri. 

1. Per **Gruppi di parametri** scegliere il gruppo di parametri **wlmtutorial** creato in precedenza. 

1. Scegliere **Salva le modifiche** per associare il gruppo di parametri. 

   Il cluster viene aggiornato con il gruppo di parametri modificato. Tuttavia, è necessario riavviare il cluster affinché le modifiche vengano applicate anche al database.

1. Scegliere il cluster, quindi selezionare **Riavvia** alla voce **Operazioni**. 

Dopo il riavvio del cluster, il suo stato torna a essere **Available (Disponibile)**. 

## Sezione 3: instradamento delle query alle code in base ai gruppi di utenti e ai gruppi di query
<a name="tutorial-wlm-routing-queries-to-queues"></a>

Ora il tuo cluster è associato a un nuovo gruppo di parametri e hai configurato WLM. Successivamente, eseguire alcune query per vedere come Amazon Redshift le instrada sulle code per l'elaborazione.

### Fase 1: visualizzazione della configurazione delle code di query nel database
<a name="tutorial-wlm-view-query-config"></a>

Verificare che la configurazione WLM del database sia quella prevista.

#### Per visualizzare la configurazione delle code di query
<a name="how-to-wlm-view-query-config"></a>

1. Apri RSQL ed esegui la query seguente. La query utilizza la vista WLM\$1QUEUE\$1STATE\$1VW creata in [Fase 1: creazione della vista WLM\$1QUEUE\$1STATE\$1VW](#tutorial-wlm-create-queue-state-view). Se prima del riavvio del cluster al database è già connessa una sessione, sarà necessario riconnetterla.

   ```
   select * from wlm_queue_state_vw;
   ```

   Di seguito è riportato un risultato di esempio.

   ```
   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
   ```

   Confronta questi risultati on quelli ricevuti in [Fase 1: creazione della vista WLM\$1QUEUE\$1STATE\$1VW](#tutorial-wlm-create-queue-state-view). Come puoi notare, ora sono presenti due code aggiuntive. La coda 1 ora è la coda per il gruppo di query di verifica, mentre la coda 2 è quella per il gruppo di utenti amministratori.

   La coda 3 è quella predefinita. L'ultima coda nell'elenco è sempre la coda predefinita. Si tratta della coda a cui vengono instradate le query se non è specificato un gruppo di utenti o di query.

1. Esegui la query seguente per verificare che venga eseguita nella coda 3.

   ```
   select * from wlm_query_state_vw;
   ```

   Di seguito è riportato un risultato di esempio.

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

### Fase 2: esecuzione di una query tramite la coda del gruppo di query
<a name="tutorial-wlm-query-group"></a>

#### Per eseguire una query tramite la coda del gruppo di query
<a name="how-to-wlm-query-group"></a>

1. Eseguire la seguente query per instradarla al gruppo di query `test`.

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

1. Dall'altra finestra RSQL esegui la query seguente.

   ```
   select * from wlm_query_state_vw;
   ```

   Di seguito è riportato un risultato di esempio.

   ```
   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 query è stata instradata al gruppo di query di verifica, che ora è la coda 1.

1. Seleziona tutto nella vista dello stato della coda.

   ```
   select * from wlm_queue_state_vw;
   ```

   Sarà visualizzato un risultato simile al seguente.

   ```
   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. Reimposta il gruppo di query ed esegui nuovamente la query lunga:

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

1. Eseguire le query sulle viste per vedere i risultati.

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

   Di seguito sono riportati i risultati di esempio.

   ```
   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
   ```

   Il risultato dovrebbe indicare che la query è ora nuovamente in esecuzione nella coda 3.

### Fase 3: creazione di un utente e un gruppo di database
<a name="tutorial-wlm-create-db-user-and-group"></a>

Prima di poter eseguire una query in questa coda, dovrai creare il gruppo di utenti nel database e aggiungere un utente al gruppo. Quindi accederai con RSQL utilizzando le nuove credenziali utente ed eseguirai le query. Per creare utenti di database, è necessario eseguire le query come utente con privilegi avanzati, ad esempio l'amministratore.

#### Per creare un nuovo gruppo di utenti e un nuovo utente di database
<a name="how-to-wlm-create-db-user-and-group"></a>

1. Nel database crea un nuovo utente di database denominato `adminwlm` eseguendo il comando seguente in una finestra RSQL.

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

1. Quindi eseguire i comandi seguenti per creare il nuovo gruppo di utenti e aggiungervi il nuovo utente `adminwlm`.

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

### Fase 4: esecuzione di una query tramite la coda del gruppo di utenti
<a name="tutorial-wlm-user-group-query"></a>

Successivamente eseguirai una query e la instraderai alla coda del gruppo di utenti. Questa operazione viene eseguita quando si intende instradare la query a una coda configurata per gestire il tipo di query che si desidera eseguire.

#### Per eseguire una query tramite la coda del gruppo di utenti
<a name="how-to-wlm-user-group-query"></a>

1. Nella finestra RSQL 2 esegui le query seguenti per passare all'account `adminwlm` ed esegui una query con questo account.

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

1. Nella finestra RSQL 1 esegui la query seguente per vedere la coda a cui vengono instradate le query.

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

   Di seguito sono riportati i risultati di esempio.

   ```
   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 coda in viene eseguita questa query è la 2, ovvero la coda dell'utente `admin`. Le query che esegui avendo effettuato l'accesso come questo utente verranno seguite nella coda 2, a meno che non specifichi un gruppo di code diverso da utilizzare. La coda scelta dipende dalle regole di assegnazione delle code. Per ulteriori informazioni, consulta [Regole di assegnazione delle code WLM](cm-c-wlm-queue-assignment-rules.md). 

1. Ora esegui la query seguente dalla finestra RSQL 2.

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

1. Nella finestra RSQL 1 esegui la query seguente per vedere la coda a cui vengono instradate le query.

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

   Di seguito sono riportati i risultati di esempio.

   ```
   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. Al termine, reimposta il gruppo di query.

   ```
   reset query_group;
   ```

## Sezione 4: utilizzo di wlm\$1query\$1slot\$1count per ignorare temporaneamente il livello di simultaneità in una coda
<a name="tutorial-wlm-query-slot-count"></a>

Può accadere che gli utenti abbiano l'esigenza temporanea di un numero maggiore di risorse per una query specifica. In questo caso possono utilizzare l'impostazione di configurazione wlm\$1query\$1slot\$1count per ignorare temporaneamente il modo in cui gli slot vengono allocati in una coda di query. Gli *slot* sono unità di memoria e CPU utilizzati per elaborare le query. È possibile ignorare il numero di slot nel caso di query occasionali che richiedono grandi quantità di risorse nel cluster, ad esempio quando si esegue un'operazione VACUUM nel database. 

Potresti trovare che gli utenti spesso devono impostare wlm\$1query\$1slot\$1count per determinati tipi di query. In tal caso, regola la configurazione WLM e fornisci agli utenti una coda più adatta alle esigenze delle loro query. Per ulteriori informazioni su come ignorare temporaneamente il livello di simultaneità utilizzando il numero di slot, consultare [wlm\$1query\$1slot\$1count](r_wlm_query_slot_count.md).

### Fase 1: come ignorare il livello di simultaneità utilizzando wlm\$1query\$1slot\$1count
<a name="tutorial-wlm-override-slot-count"></a>

Ai fini del presente tutorial, eseguiremo la stessa query SELECT di lunga durata. La query verrà eseguita come utente `adminwlm` utilizzando wlm\$1query\$1slot\$1count per aumentare il numero di slot disponibili per la query.

#### Per ignorare il livello di simultaneità utilizzando wlm\$1query\$1slot\$1count
<a name="how-to-wlm-override-slot-count"></a>

1. Aumentare il limite per la query per essere sicuri di disporre di tempo sufficiente per eseguire la query sulla vista WLM\$1QUERY\$1STATE\$1VW e vedere il risultato. 

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

1. Esegui la query WLM\$1QUERY\$1STATE\$1VW con l'utente amministratore per vederne l'esecuzione.

   ```
   select * from wlm_query_state_vw;
   ```

   Di seguito è riportato un risultato di esempio.

   ```
   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
   ```

   Il numero di slot per la query è 3. Ciò significa che la query utilizza tutti e tre gli slot per l'elaborazione, allocando tutte le risorse nella coda alla query.

1. Ora esegui la seguente query.

   ```
   select * from WLM_QUEUE_STATE_VW;
   ```

   Di seguito è riportato un risultato di esempio.

   ```
   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
   ```

   L'impostazione di configurazione di wlm\$1query\$1slot\$1count ha validità solo per la sessione corrente. Se la sessione scade o un altro utente esegue una query, viene utilizzata la configurazione WLM.

1. Reimpostare il numero di slot ed eseguire nuovamente il test.

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

   Di seguito sono riportati i risultati di esempio.

   ```
   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
   ```

### Fase 2: esecuzione delle query da sessioni diverse
<a name="tutorial-wlm-run-queries-from-different-sessions"></a>

A questo punto eseguire le query da sessioni diverse.

#### Per eseguire le query da sessioni diverse
<a name="how-to-wlm-run-queries-from-different-sessions"></a>

1. Nelle finestre RSQL 1 e 2 esegui la query seguente per utilizzare il gruppo di query di test.

   ```
   set query_group to test;
   ```

1. Nella finestra RSQL 1 esegui la seguente query di lunga durata.

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

1. Poiché la query di lunga durata è ancora in esecuzione nella finestra RSQL 1, esegui quanto segue. Questi comandi aumentano il numero di slot per utilizzare tutti gli slot per la coda, quindi avviano l'esecuzione della query di lunga durata.

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

1. Apri una terza finestra RSQL ed esegui una query sulle viste per vedere i risultati.

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

   Di seguito sono riportati i risultati di esempio.

   ```
   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
   ```

   Nota che la prima query utilizza uno degli slot assegnati alla coda 1 per eseguire la query. Inoltre, tieni presente che una query è in attesa nella coda (dove `queued` è `1` e `state` è `QueuedWaiting`). Una volta completata la prima query, inizierà l'esecuzione della seconda. Ciò accade perché entrambe le query sono instradate al gruppo di query `test` e la seconda deve attendere che siano disponibili slot sufficienti per iniziare l'elaborazione.

## Sezione 5: pulizia delle risorse
<a name="tutorial-wlm-cleaning-up-resources"></a>

Il tuo cluster genera dei costi fino a che è in esecuzione. Una volta completato questo tutorial, ripristinare lo stato precedente dell'ambiente seguendo la procedura descritta in [Scoprire risorse aggiuntive e reimpostare l'ambiente](https://docs.aws.amazon.com/redshift/latest/gsg/rs-gsg-clean-up-tasks.html) nella *Guida alle operazioni di base di Amazon Redshift*.

Per ulteriori informazioni sulla funzionalità WLM, consultare [Gestione dei carichi di lavoro](cm-c-implementing-workload-management.md).