O Amazon Redshift não permitirá mais a criação de UDFs do Python a partir do Patch 198. As UDFs do Python existentes continuarão a funcionar normalmente até 30 de junho de 2026. Para ter mais informações, consulte a [publicação de blog ](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/). 

# Implementar o WLM manual
<a name="cm-c-defining-query-queues"></a>

Com WLM manual, é possível gerenciar a performance do sistema e a experiência dos usuários modificando a configuração de WLM a fim de criar filas separadas para as consultas demoradas e as rápidas.

Quando os usuários executam consultas no Amazon Redshift, as consultas são encaminhadas para filas de consulta. Cada fila de consultas contém alguns slots de consulta. Cada fila recebe uma parte da memória disponível do cluster. A memória de uma fila é dividida entre os slots de consulta da fila. Você pode habilitar o Amazon Redshift para gerenciar a simultaneidade de consultas com WLM automático. Para obter mais informações, consulte [Implementar o WLM automático](automatic-wlm.md).

Como alternativa, é possível configurar as propriedades do WLM para cada fila de consultas. Faça isso especificando a maneira pela qual a memória é alocada entre slots e como as consultas podem ser roteadas para filas específicas em runtime. Você também pode configurar as propriedades de WLM para cancelar consultas demoradas.

Por padrão, o Amazon Redshift configura as seguintes filas de consulta:
+  **Uma fila de usuários avançados** 

  A fila de superusuários é reservada somente para estes e não pode ser configurada. Use essa fila quando precisar executar consultas que afetam o sistema ou para fins de solução de problemas. Por exemplo, use essa fila quando você precisar cancelar a consulta demorada de um usuário ou adicionar usuários ao banco de dados. Não use para realizar consultas de rotina. A fila não é exibida no console, mas aparece nas tabelas do sistema do banco de dados como a quinta fila. Para executar uma consulta na fila de superusuários, um usuário deve estar conectado como superusuário e executar a consulta usando o grupo de consultas `superuser` predefinido.
+  **Uma fila de usuários padrão** 

  A fila padrão é configurada inicialmente para executar simultaneamente cinco consultas. Ao usar WLM manual, você pode alterar as propriedades de simultaneidade, tempo limite e alocação da memória da fila padrão, mas não pode especificar grupos de usuários ou consultas. A fila padrão deve ser a última na configuração do WLM. Algumas consultas que não são roteadas para outras filas são executadas na fila padrão. 

As filas de consultas são definidas na configuração do WLM. A configuração do WLM é um parâmetro editável (`wlm_json_configuration`) em um parameter group, que pode ser associado a um ou mais clusters. Para obter mais informações, consulte “[Configurar o gerenciamento de workload](https://docs.aws.amazon.com/redshift/latest/mgmt/workload-mgmt-config.html)” no *Guia de gerenciamento de clusters do Amazon Redshift*. 

Você pode adicionar filas de consultas adicionais à configuração do WLM padrão, até um total de oito filas de usuários. Você pode configurar o seguinte para cada fila de consultas: 
+ Modo de escalabilidade da simultaneidade 
+ Nível de simultaneidade 
+ User groups (Grupos de usuários) 
+ Grupos de consultas 
+ Porcentagem de memória do WLM a ser usada
+ Tempo limite do WLM
+ Salto na fila de consultas do WLM
+ Regras de monitoramento de consulta

## Modo de escalabilidade da simultaneidade
<a name="concurrency-scaling-mode"></a>

Quando a escalabilidade de simultaneidade está habilitada, o Amazon Redshift adiciona automaticamente capacidade de cluster quando necessário para processar um aumento nas consultas de leitura e gravação simultâneas. Os usuários veem os dados mais recentes, sejam as consultas executadas no cluster principal ou em um cluster de escalabilidade da simultaneidade. 

Gerencie quais consultas são enviadas para o cluster de escalabilidade da simultaneidade configurando filas do WLM. Ao habilitar a escalabilidade de simultaneidade para uma fila, as consultas qualificadas são enviadas ao cluster de escalabilidade de simultaneidade em vez de aguardar na fila. Para obter mais informações, consulte [Escalabilidade simultânea.](concurrency-scaling.md).

## Nível de simultaneidade
<a name="cm-c-defining-query-queues-concurrency-level"></a>

As consultas em uma fila são executadas simultaneamente até que atinjam o número de slots de consulta do WLM ou o nível de *simultaneidade*, definido para essa fila. Em seguida, as consultas subsequentes aguardam na fila.

**nota**  
O nível de simultaneidade do WLM é diferente do número de conexões de usuário simultâneas que podem ser estabelecidas com um cluster. Para obter mais informações, consulte “[Conectar-se a um cluster](https://docs.aws.amazon.com/redshift/latest/mgmt/connecting-to-cluster.html)” no *Guia de gerenciamento de clusters do Amazon Redshift*.

Em uma configuração de WLM automático (recomendada), o nível de simultaneidade é definido como **Automático**. O Amazon Redshift aloca memória dinamicamente para consultas, o que posteriormente determina quantas serão executadas simultaneamente. Isso se baseia nos recursos necessários para consultas em execução e consultas em fila. O WLM automático não é configurável. Para obter mais informações, consulte [Implementar o WLM automático](automatic-wlm.md). 

Em uma configuração de WLM manual, o Amazon Redshift aloca estaticamente uma quantidade fixa de memória para cada fila. A memória da fila é dividida igualmente entre os slots de consulta. Para ilustrar, se uma fila receber 20% da memória de um cluster e tiver 10 slots, cada consulta receberá 2% da memória do cluster. A alocação de memória permanece fixa, independentemente do número de consultas em execução simultânea. Devido a essa alocação de memória fixa, consultas executadas inteiramente na memória quando o número de slots é 5 talvez gravem resultados intermediários em disco, caso o número de slots seja aumentado para 20. Nesse caso, a parte de cada consulta na memória da fila é reduzida de 1/5 para 1/20. A E/S de disco adicional pode afetar a performance. 

O número máximo de slots para todas as filas definidas pelo usuário é 50. Isso limita o total de slots para todas as filas, incluindo a fila padrão. A única fila que não está sujeita ao limite é a fila reservada para superusuários.

Por padrão, as filas do WLM manuais têm um nível de simultaneidade de 5. O workload pode se beneficiar de um nível de simultaneidade superior em determinados casos, como o seguinte:
+ Se muitas consultas pequenas forem forçadas a aguardar consultas demoradas, crie uma fila à parte com um número de slots superior e atribua as consultas menores a essa fila. Uma fila com um nível de simultaneidade superior tem menos memória alocada para cada slot de consulta, mas as consultas menores exigem menos memória.
**nota**  
Se você habilitar a aceleração de consultas breves (SQA), o WLM priorizará automaticamente as consultas breves sobre as consultas demoradas, para que você não precise de uma fila separada para consultas breves na maioria dos fluxos de trabalho. Para obter mais informações, consulte [Aceleração de consulta breve](wlm-short-query-acceleration.md). 
+ Se você tiver várias consultas que acessam dados individualmente em uma única fatia, configure uma fila do WLM à parte para executar essas consultas simultaneamente. O Amazon Redshift atribui consultas simultâneas a fatias separadas, o que permite executar várias consultas em paralelo em várias fatias. Por exemplo, se uma consulta for um agregado simples com um predicado na chave de distribuição, os dados da consulta estarão localizados em uma única fatia. 

### Um exemplo de WLM manual
<a name="cm-c-defining-query-queues-concurrency-level-example"></a>

 Este exemplo é um cenário simples de WLM manual para mostrar como os slots e a memória podem ser alocados. Implemente o WLM manual com três filas, que são as seguintes: 
+ *fila de ingestão de dados*: configurada para ingerir dados. Recebe 20% da memória do cluster e tem 5 slots. Consequentemente, 5 consultas podem ser executadas simultaneamente na fila e cada uma recebe 4% da memória.
+ *fila de cientistas de dados*: projetada para consultas que consomem muita memória. Recebe 40% da memória do cluster e tem 5 slots. Consequentemente, 5 consultas podem ser executadas simultaneamente e cada uma recebe 8% da memória.
+ *fila padrão*: projetada para a maioria dos usuários na organização. Isso inclui grupos de vendas e contabilidade, que normalmente têm consultas de curta ou média duração que não são complicadas. Recebe 40% da memória do cluster e tem 40 slots. Essa fila pode executar 40 consultas simultaneamente, e cada consulta recebe 1% da memória. Esse é o número máximo de slots que essa fila pode ter, pois o limite total entre todas as filas é 50.

Se você estiver realizando WLM automático e sua workload exigir execução simultânea de mais de 15 consultas, recomendamos ativar a escalabilidade da simultaneidade. Isso ocorre porque o aumento da contagem de slots de consulta acima de 15 pode criar contenção de recursos do sistema e limitar a throughput geral de um único cluster. Com a escalabilidade da simultaneidade, você pode executar centenas de consultas simultâneas até um número configurado de clusters de escalabilidade da simultaneidade. O número de clusters de escalabilidade da simultaneidade é controlado por [max\$1concurrency\$1scaling\$1clusters](r_max_concurrency_scaling_clusters.md). Para obter mais informações sobre a escalabilidade da simultaneidade, consulte [Escalabilidade simultânea.](concurrency-scaling.md). 

Para obter mais informações, consulte [Aprimoramento do desempenho das consultas](query-performance-improvement-opportunities.md). 

## User groups (Grupos de usuários)
<a name="cm-c-defining-query-queues-user-groups"></a>

Você pode atribuir um conjunto de grupos de usuários a uma fila especificando o nome de cada grupo de usuários ou usando curingas. Quando um membro de um grupo de usuários listado executa uma consulta, esta é executada na fila correspondente. Não há limite definido quanto ao número de grupos de usuários que podem ser atribuídos a uma fila. Para obter mais informações, consulte [Atribuir consultas a filas com base em grupos de usuários](cm-c-executing-queries.md#cm-c-executing-queries-assigning-queries-to-queues-based-on-user-groups). 

## Funções de usuário
<a name="cm-c-defining-query-queues-user-roles"></a>

Você pode atribuir um conjunto de perfis de usuário a uma fila especificando o nome de cada perfil de usuário ou usando curingas. Quando um membro de um perfil de usuário listado executa uma consulta, esta é executada na fila correspondente. Não há limite definido quanto ao número de perfis de usuário que podem ser atribuídos a uma fila. Para obter mais informações, consulte [Atribuir consultas a filas com base em perfis de usuário](cm-c-executing-queries.md#cm-c-executing-queries-assigning-queries-to-queues-based-on-user-roles). 

## Grupos de consultas
<a name="cm-c-defining-query-queues-query-groups"></a>

Você pode atribuir um conjunto de grupos de consultas a uma fila especificando o nome de cada grupo de consultas ou usando curingas. Um grupo de consultas é apenas um rótulo. No tempo de execução, é possível atribuir o rótulo do grupo de consultas a uma série de consultas. Todas as consultas atribuídas a um grupo de consultas listado são executadas na fila correspondente. Não há limite definido para o número de grupos de consultas que podem ser atribuídos a uma fila. Para obter mais informações, consulte [Atribuir uma consulta a um grupo de consultas](cm-c-executing-queries.md#cm-c-executing-queries-assigning-a-query-to-a-query-group). 

## Curingas
<a name="wlm-wildcards"></a>

Se os curingas forem permitidos na configuração de fila do WLM, você poderá atribuir grupos de usuários e consultas a uma fila individualmente ou usando curingas em estilo shell do Unix. A comparação de padrões não diferencia maiúsculas de minúsculas. 

Por exemplo, o caractere curinga “\$1” corresponde a qualquer número de caracteres. Portanto, se você adicionar `dba_*` à lista de grupos de usuários para uma fila, qualquer consulta executada por usuário, que pertença a um grupo com um nome que começa com `dba_`, será atribuída a essa fila. Os exemplos são `dba_admin` ou `DBA_primary`. O caractere curinga “?” corresponde a qualquer caractere único. Portanto, se a fila incluir o grupo de usuários `dba?1`, os grupos de usuários chamados `dba11` e `dba21` corresponderão, mas `dba12` não corresponderá. 

Os curingas são desativados por padrão.

## Porcentagem de memória do WLM a ser usada
<a name="wlm-memory-percent"></a>

Em uma configuração de WLM automático, a porcentagem de memória é definida como **auto**. Para obter mais informações, consulte [Implementar o WLM automático](automatic-wlm.md). 

Em uma configuração de WLM manual, para especificar o valor de memória disponível alocado para uma consulta, você pode definir o parâmetro `WLM Memory Percent to Use`. Por padrão, cada fila definida pelo usuário recebe uma parte igual da memória disponível para consultas definidas pelo usuário. Por exemplo, se você tiver quatro filas definidas pelo usuário, cada fila receberá 25 por cento da memória disponível. A fila de superusuários tem a própria memória alocada e não pode ser modificada. Para alterar a alocação, você atribui uma porcentagem de memória em inteiro a cada fila, até um total de 100 por cento. Qualquer memória não alocada é gerenciada pelo Amazon Redshift e pode ser temporariamente fornecida a uma fila se a fila solicitar memória adicional para processamento. 

Por exemplo, se configurar quatro filas, você poderá alocar a memória da seguinte maneira: 20 por cento, 30 por cento, 15 por cento, 15 por cento. Os 20 por cento restantes permanecem desalocados e são gerenciados pelo serviço.

## Tempo limite do WLM
<a name="wlm-timeout"></a>

O tempo limite do WLM (`max_execution_time`) está obsoleto. Em vez disso, crie uma regra de monitoramento de consulta (QMR) usando `query_execution_time` para limitar o tempo de execução decorrido para uma consulta. Para obter mais informações, consulte [Regras de monitoramento de consulta do WLM](cm-c-wlm-query-monitoring-rules.md). 

Para limitar o valor de tempo em que as consultas em uma determinada fila do WLM têm permissão para serem usadas, você pode definir o valor de tempo limite do WLM para cada fila. O parâmetro tempo limite especifica a quantidade de tempo, em milissegundos, durante o qual o Amazon Redshift aguarda a execução de uma consulta antes de cancelar ou ignorar a consulta. O tempo limite se baseia no tempo de execução da consulta e não inclui o tempo gasto esperando em uma fila. 

O WLM tenta saltar as instruções [CREATE TABLE AS](r_CREATE_TABLE_AS.md) (CTAS) e as consultas somente leitura, como instruções SELECT. Consultas que não podem ser saltadas são canceladas. Para obter mais informações, consulte [Salto na fila de consultas do WLM](wlm-queue-hopping.md).

O tempo limite do WLM não se aplica a uma consulta que tenha atingido o estado de retorno. Para exibir o estado de uma consulta, consulte a tabela de sistema [STV\$1WLM\$1QUERY\$1STATE](r_STV_WLM_QUERY_STATE.md). As instruções COPY e as operações de manutenção, como ALTER, ANALYZE e VACUUM, não estão sujeitas ao tempo limite do WLM.

A função de tempo limite do WLM é semelhante ao parâmetro de configuração [statement\$1timeout](r_statement_timeout.md). A diferença é que, enquanto o parâmetro de configuração `statement_timeout` se aplica a todo o cluster, o tempo limite do WLM é específico para uma única fila na configuração do WLM. 

Se [statement\$1timeout](r_statement_timeout.md) também for especificado, o menor statement\$1timeout e tempo limite do WLM (max\$1execution\$1time) serão usados. 

## Regras de monitoramento de consulta
<a name="wlm-query-monitoring-rules"></a>

As regras de monitoramento de consultas definem limites de performance baseados em métricas para filas do WLM e especificam qual ação tomar quando uma consulta vai além desses limites. Por exemplo, para uma fila dedicada a consultas rápidas, convém criar uma regra que cancele consultas executadas por mais de 60 segundos. Para acompanhar consultas mal projetadas, convém ter outra regra que registre consultas que contenham loops aninhados. Para obter mais informações, consulte [Regras de monitoramento de consulta do WLM](cm-c-wlm-query-monitoring-rules.md).

# Salto na fila de consultas do WLM
<a name="wlm-queue-hopping"></a>

Com o Amazon Redshift, é possível gerenciar a simultaneidade de workloads e a alocação de recursos habilitando o salto na fila de consultas do gerenciamento de workloads (WLM). Esse recurso permite que as consultas “saltem” temporariamente de uma fila atribuída para uma fila de maior prioridade quando os recursos estão disponíveis, melhorando o desempenho geral da consulta e a utilização do sistema. As seções a seguir apresentam orientações detalhadas sobre como configurar e utilizar o salto na fila de consultas do WLM no Amazon Redshift.

Uma consulta pode ser saltada devido a um [tempo limite do WLM](cm-c-defining-query-queues.md#wlm-timeout) ou uma [ação de salto da regra de monitoramento de consultas (QMR)](cm-c-wlm-query-monitoring-rules.md#cm-c-wlm-defining-query-monitoring-rules). Só é possível saltar consultas em uma configuração manual do WLM. 

Quando uma consulta é saltada, o WLM tenta rotear a consulta para a próxima fila correspondente com base nas [regras de atribuição de filas do WLM](cm-c-wlm-queue-assignment-rules.md). Se a consulta não corresponder a qualquer outra definição de fila, ela será cancelada. Ela não é atribuída à fila padrão. 

## Ações de tempo limite do WLM
<a name="wlm-queue-hopping-summary"></a>

A tabela a seguir resume o comportamento dos diferentes tipos de consultas com um tempo limite do WLM.

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/redshift/latest/dg/wlm-queue-hopping.html)

## Salto na fila de tempo limite do WLM
<a name="wlm-timeout-queue-hopping"></a>

O WLM salta os seguintes tipos de consultas quando seus tempos limite são expirados:
+ Consultas somente leitura, como instruções SELECT que estejam em estado no WLM `running`. Para encontrar o estado do WLM de uma consulta, exiba a coluna STATE na tabela do sistema [STV\$1WLM\$1QUERY\$1STATE](r_STV_WLM_QUERY_STATE.md). 
+ Instruções CREATE TABLE AS (CTAS). O salto de filas do WLM oferece suporte para as instruções CTAS definidas pelo usuário e para as geradas pelo sistema. 
+ Instruções SELECT INTO.

As consultas que não estão sujeitas ao tempo limite do WLM continuam a ser executadas na fila original até que sejam concluídas. Os seguintes tipos de consultas não estão sujeitos ao tempo limite do WLM:
+ Instruções COPY
+ Operações de manutenção, como ALTER, ANALYZE e VACUUM
+ Consultas somente leitura, como instruções SELECT que estejam em estado no WLM `returning`. Para encontrar o estado do WLM de uma consulta, exiba a coluna STATE na tabela do sistema [STV\$1WLM\$1QUERY\$1STATE](r_STV_WLM_QUERY_STATE.md). 

Consultas que não estão qualificadas para a operação de salto por tempo limite do WLM são canceladas quando seus tempos limite expiram. Os seguintes tipos de consultas não estão qualificados para a operação de salto por tempo limite do WLM:
+ Instruções INSERT, UPDATE e DELETE
+ Instruções UNLOAD
+ Funções definidas pelo usuário (UDFs)

## Consultas reatribuídas e reiniciadas devido ao tempo limite do WLM
<a name="wlm-timeout-reassigned-and-restarted-queries"></a>

Quando uma consulta é saltada e nenhuma fila correspondente é encontrada, a consulta é cancelada.

Quando uma consulta é saltada e uma fila correspondente é encontrada, o WLM tenta reatribuir a consulta à nova fila. Caso não seja possível reatribuir uma consulta, ela é reiniciada em uma fila nova, como descrito a seguir.

Uma consulta somente será reatribuída se todas as afirmações a seguir forem verdadeiras:
+ Uma fila correspondente foi encontrada.
+ A fila nova tem slots livres suficientes para executar a consulta. Uma consulta pode exigir vários slots se o parâmetro [wlm\$1query\$1slot\$1count](r_wlm_query_slot_count.md) foi definido com um valor maior que 1.
+ A fila nova tem, no mínimo, a mesma quantidade de memória disponível usada pela consulta no momento. 

Se a consulta for reatribuída, ela continuará sendo executada na fila nova. Os resultados intermediários são conservados, de forma que o efeito sobre o tempo total de execução é mínimo. 

Se a consulta não puder ser reatribuída, ela será cancelada e reiniciada na nova fila. Os resultados intermediários são excluídos. A consulta espera na fila e inicia a execução quando há slots suficientes disponíveis.

## Ações de salto do QMR
<a name="qmr-hop-action-queue-hopping"></a>

A tabela a seguir resume o comportamento dos diferentes tipos de consultas com uma ação de salto do QMR.

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/redshift/latest/dg/wlm-queue-hopping.html)

Para saber se uma consulta que foi saltada pelo QMR foi reatribuída, reiniciada ou cancelada, consulte a [STL\$1WLM\$1RULE\$1ACTION](r_STL_WLM_RULE_ACTION.md)tabela de log do sistema.

## Consultas reatribuídas e reiniciadas devido à ação de salto do QMR
<a name="qmr-hop-action-reassigned-and-restarted-queries"></a>

Quando uma consulta é saltada e nenhuma fila correspondente é encontrada, a consulta é cancelada.

Quando uma consulta é saltada e uma fila correspondente é encontrada, o WLM tenta reatribuir a consulta à nova fila. Caso não seja possível reatribuir uma consulta, ela será reiniciada na fila nova ou continuará a ser executada na fila original, como descrito a seguir.

Uma consulta somente será reatribuída se todas as afirmações a seguir forem verdadeiras:
+ Uma fila correspondente foi encontrada.
+ A fila nova tem slots livres suficientes para executar a consulta. Uma consulta pode exigir vários slots se o parâmetro [wlm\$1query\$1slot\$1count](r_wlm_query_slot_count.md) foi definido com um valor maior que 1.
+ A fila nova tem, no mínimo, a mesma quantidade de memória disponível usada pela consulta no momento. 

Se a consulta for reatribuída, ela continuará sendo executada na fila nova. Os resultados intermediários são conservados, de forma que o efeito sobre o tempo total de execução é mínimo. 

Caso não seja possível reatribuir uma consulta, ela será reiniciada ou continuará a ser executada na fila original. Se a consulta for reiniciada, ela será cancelada e reiniciada na nova fila. Os resultados intermediários são excluídos. A consulta espera na fila e inicia a execução quando há slots suficientes disponíveis.

# Tutorial: Configuração de filas de gerenciamento do workload (WLM) manual
<a name="tutorial-configuring-workload-management"></a>

Com o Amazon Redshift, é possível configurar filas do gerenciamento de workloads (WLM) manual para priorizar e alocar recursos a diferentes tipos de consulta e usuário. As filas do WLM manual permitem que você controle as configurações de memória e simultaneidade de filas específicas, garantindo que as workloads essenciais recebam os recursos necessários e evitando que consultas de baixa prioridade monopolizem o sistema. As seções a seguir orientam você no processo de criação e configuração de filas do WLM manual no Amazon Redshift para atender aos requisitos de gerenciamento de workloads. 

## Visão geral
<a name="tutorial-wlm-overview"></a>

Recomendamos configurar o gerenciamento automático de workload (WLM) no Amazon Redshift. Para obter mais informações sobre o WLM automático, consulte [Gerenciamento do workload](cm-c-implementing-workload-management.md). No entanto, se você precisar de várias filas WLM, este tutorial o orienta no processo de configuração do gerenciamento de workload manual (WLM) no Amazon Redshift. Ao configurar o WLM manual, é possível melhorar a performance de consulta e a alocação de recursos no cluster.

O Amazon Redshift roteia as consultas do usuário para filas para processamento. O WLM define como essas consultas são roteadas para as filas. Por padrão, o Amazon Redshift tem duas filas disponíveis para consultas: uma para superusuários e outra para usuários. A fila de superusuários não pode ser configurada e processa somente uma consulta por vez. Você deve reservar essa fila somente para fins de solução de problemas. A fila de usuários pode processar até cinco consultas por vez, mas você pode configurá-la alterando o nível de simultaneidade da fila, se necessário. 

Quando tem diversos usuários executando consultas no banco de dados, você pode achar outra configuração mais eficiente. Por exemplo, se executarem operações que exijam muitos recursos, como VACUUM, alguns usuários poderão ter um impacto negativo sobre consultas menos intensivas, como relatórios. Convém considerar adicionar filas e configurá-las para workloads diferentes. 

**Tempo estimado:** 75 minutos

**Custo estimado:** 50 centavos

### Pré-requisitos
<a name="tutorial-wlm-prereq"></a>

Você precisa de um cluster do Amazon Redshift, do banco de dados TICKIT de amostra e da ferramenta cliente Amazon Redshift RSQL. Se você ainda não fez essa configuração, consulte o [Guia de conceitos básicos do Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/gsg/new-user.html) e o [Amazon Redshift RSQL](https://docs.aws.amazon.com/redshift/latest/mgmt/rsql-query-tool.html). 

### Seções
<a name="tutorial-wlm-steps"></a>
+ [Seção 1: Compreender o comportamento do processamento de filas padrão](#tutorial-wlm-understanding-default-processing)
+ [Seção 2: Modificar a configuração da fila de consultas do WLM](#tutorial-wlm-modifying-wlm-configuration)
+ [Seção 3: Rotear consultas para filas com base em grupos de usuários e grupos de consultas](#tutorial-wlm-routing-queries-to-queues)
+ [Seção 4: Usar wlm\$1query\$1slot\$1count para substituir temporariamente o nível de simultaneidade em uma fila](#tutorial-wlm-query-slot-count)
+ [Seção 5: Limpar os recursos](#tutorial-wlm-cleaning-up-resources)

## Seção 1: Compreender o comportamento do processamento de filas padrão
<a name="tutorial-wlm-understanding-default-processing"></a>

Antes de começar a configurar o WLM manual, é útil entender o comportamento padrão do processamento de fila no Amazon Redshift. Nesta seção, crie duas visualizações de banco de dados que retornam informações de diversas tabelas do sistema. Depois, execute algumas consultas de teste para saber como as consultas são roteadas por padrão. Para obter mais informações sobre tabelas de sistema, consulte [Referência de visualizações e tabelas do sistema](cm_chap_system-tables.md). 

### Etapa 1: Criar a visualização WLM\$1QUEUE\$1STATE\$1VW
<a name="tutorial-wlm-create-queue-state-view"></a>

Nesta etapa, crie uma visualização chamada WLM\$1QUEUE\$1STATE\$1VW. Essa visualização retorna informações das tabelas de sistema a seguir.
+ [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)

Essa visualização será usada ao longo do tutorial para monitorar o que acontecerá com as filas depois que alterar a configuração do WLM. A tabela a seguir descreve os dados retornados pela visualização WLM\$1QUEUE\$1STATE\$1VW. 

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

#### Como criar a visualização WLM\$1QUEUE\$1STATE\$1VW
<a name="how-to-wlm-create-queue-state-view"></a>

1. Abra o [Amazon Redshift RSQL](https://docs.aws.amazon.com/redshift/latest/mgmt/rsql-query-tool.html) e conecte-se ao seu banco de dados de amostra TICKIT. Se você não tiver esse banco de dados, consulte [Pré-requisitos](#tutorial-wlm-prereq).

1. Execute a consulta a seguir para criar a visualização 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. Execute a consulta a seguir para ver as informações contidas pela visualização.

   ```
   select * from wlm_queue_state_vw;
   ```

   Este é um resultado de exemplo.

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

### Etapa 2: Criar a visualização WLM\$1QUERY\$1STATE\$1VW
<a name="tutorial-wlm-create-query-state-view"></a>

Nesta etapa, crie uma visualização chamada WLM\$1QUERY\$1STATE\$1VW. Essa visualização retorna informações da tabela de sistema [STV\$1WLM\$1QUERY\$1STATE](r_STV_WLM_QUERY_STATE.md).

Essa visualização será usada ao longo do tutorial para monitorar as consultas em execução. A tabela a seguir descreve os dados retornados pela visualização WLM\$1QUERY\$1STATE\$1VW.

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

#### Como criar a visualização WLM\$1QUERY\$1STATE\$1VW
<a name="how-to-wlm-create-query-state-view"></a>

1. Em RSQL, execute a consulta a seguir para criar a visualização 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. Execute a consulta a seguir para ver as informações contidas pela visualização.

   ```
   select * from wlm_query_state_vw;
   ```

   Este é um resultado de exemplo.

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

### Etapa 3: Executar consultas de teste
<a name="tutorial-wlm-run-test-queries"></a>

Nesta etapa, execute consultas de várias conexões em RSQL e examine as tabelas de sistema para determinar como as consultas foram roteadas para processamento. 

Para esta etapa, são necessárias duas janelas RSQL abertas: 
+ Na janela RSQL 1, execute consultas que monitoram o estado das filas e das consultas usando as visualizações já criadas neste tutorial.
+ Na janela RSQL 2, execute consultas demoradas para alterar os resultados encontrados na janela RSQL 1.

#### Como executar as consultas de teste
<a name="how-to-wlm-run-test-queries"></a>

1. Abra duas janelas RSQL. Se já tiver uma janela aberta, você precisará somente abrir uma segunda. Você pode usar a mesma conta de usuário para ambas as conexões.

1. Na janela RSQL 1, execute a consulta a seguir.

   ```
   select * from wlm_query_state_vw;
   ```

   Este é um resultado de exemplo.

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

   Essa consulta retorna um resultado autorreferencial. A consulta em execução no momento é a instrução SELECT nesta visualização. Uma consulta nessa visualização sempre retorna pelo menos um resultado. Compare esse resultado com o resultado ocorrido depois de iniciar a consulta demorada na próxima etapa.

1. Na janela RSQL 2, execute uma consulta no banco de dados de exemplo TICKIT. Essa consulta deve ser executada por aproximadamente um minuto, de maneira que você tenha tempo de explorar os resultados das visualizações WLM\$1QUEUE\$1STATE\$1VW e WLM\$1QUERY\$1STATE\$1VW criadas anteriormente. Em alguns casos, você poderá descobrir que a consulta não é executada por tempo suficiente para consultar ambas as visualizações. Nesses casos, aumente o valor do filtro em `l.listid `para fazer com seja excutada por mais tempo.
**nota**  
Para reduzir o tempo de execução da consulta e melhorar a performance do sistema, o Amazon Redshift armazena em cache os resultados de certos tipos de consultas na memória no nó líder. Quando o cache de resultados estiver habilitado, as consultas subsequentes serão executadas mais rapidamente. Para impedir que a consulta seja executada muito rapidamente, desabilite o cache de resultados para a sessão atual.

   Para desabilitar o cache de resultados da sessão atual, defina o parâmetro [enable\$1result\$1cache\$1for\$1session](r_enable_result_cache_for_session.md) como `off`, conforme mostrado a seguir.

   ```
   set enable_result_cache_for_session to off;
   ```

   Na janela RSQL 2, execute a consulta a seguir.

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

1. Na janela RSQL 1, as consultas WLM\$1QUEUE\$1STATE\$1VW e WLM\$1QUERY\$1STATE\$1VW comparam os resultados com os resultados anteriores.

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

   Estes são resultados de exemplo.

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

Observe as seguintes diferenças entre as consultas anteriores e os resultados nesta etapa:
+ Agora existem duas linhas em WLM\$1QUERY\$1STATE\$1VW. Um resultado é a consulta autorreferencial para executar uma operação SELECT nessa visualização. O segundo resultado é a consulta demorada da etapa anterior.
+ A coluna em execução em WLM\$1QUEUE\$1STATE\$1VW aumentou de 1 a 2. Essa entrada de coluna significa que existem duas consultas em execução na fila.
+ A coluna executada é incrementada sempre que você executa uma consulta na fila.

A visualização WLM\$1QUEUE\$1STATE\$1VW é útil para ter uma visualização geral das filas e quantas consultas estão sendo processadas em cada fila. A visualização WLM\$1QUERY\$1STATE\$1VW é útil para obter uma visão mais detalhada das consultas individuais em execução no momento.

## Seção 2: Modificar a configuração da fila de consultas do WLM
<a name="tutorial-wlm-modifying-wlm-configuration"></a>

Agora que compreende como as filas funcionam por padrão, aprenda como configurar filas de consultas usando WLM manual. Nesta seção, crie e configure um novo grupo de parâmetros para o cluster. Você cria duas filas de usuários adicionais e configura-as para aceitar consultas com base no grupo de usuários das consultas ou nos rótulos dos grupos de consultas. Todas as consultas que não forem roteadas para uma dessas duas filas serão roteadas para a fila padrão em tempo de execução.

**Para criar uma configuração manual de WLM em um grupo de parâmetros**

1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon Redshift em [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).

1. No menu de navegação, escolha **Configurations** (Configurações) e **Workload management** (Gerenciamento de workload) para exibir a página **Workload management** (Gerenciamento de workload). 

1. Escolha **Create (Criar)** para exibir a janela **Create parameter group (Criar grupo de parâmetros)**. 

1. Insira **WLMTutorial** tanto para **Nome do grupo de parâmetros** como para **Descrição** e depois escolha **Criar** para criar o grupo de parâmetros. 
**nota**  
O **Parameter group name (Nome do grupo de parâmetros)** é convertido para todas letras minúsculas quando criado. 

1. Na página **Workload management (Gerenciamento do workload)**, escolha o grupo de parâmetros **wlmtutorial** para exibir a página de detalhes com guias para **Parameters (Parâmetros)** e **Workload management (Gerenciamento do workload)**. 

1. Confirme se você está na página **Workload management (Gerenciamento do workload)** e escolha **Switch WLM mode (Alternar modo WLM)** para exibir a janela **Concurrency settings (Configurações de simultaneidade)**. 

1. Escolha **Manual WLM (WLM manual)** e escolha **Save (Salvar)** para alternar para o WLM manual. 

1. Escolha **Edit workload queues (Editar filas de workload)**. 

1. Escolha **Add queue (Adicionar fila)** duas vezes para adicionar duas filas. Agora existem três filas: **Queue 1 (Fila 1)**, **Queue 2 (Fila 2)** e **Default queue (Fila padrão)**. 

1. Insira informações para cada fila da seguinte maneira: 
   + Em **Queue 1 (Fila 1)**, insira **30** para **Memory (%) (Memória (%))**, **2** para **Concurrency on main (Simultaneidade em principal)** e **test** para **Query groups (Grupos de consultas)**. Deixe as outras configurações com os valores padrão.
   + Em **Queue 2 (Fila 2)**, insira **40** para **Memory (%) (Memória (%))**, **3** para **Concurrency on main (Simultaneidade em principal)** e **admin** para **User groups (Grupos de usuários)**. Deixe as outras configurações com os valores padrão.
   + Defina o valor de **Simultaneidade na principal** para a fila padrão como um valor maior ou igual a 1. Não faça nenhuma outra alteração na **Fila padrão**. O WLM atribui a memória não alocada à fila padrão. 

1. Para salvar suas configurações, escolha **Save (Salvar)**. 

Depois, associe o grupo de parâmetros que tem a configuração de WLM manual com um cluster.

**Para associar um grupo de parâmetros com uma configuração de WLM manual a um cluster.**

1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon Redshift em [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).

1. No menu de navegação, escolha **Clusters** e, depois, **Clusters** para exibir uma lista de seus clusters. 

1. Escolha seu cluster, como `examplecluster`, para exibir os detalhes do cluster. Em seguida, escolha a guia **Properties** para exibir as propriedades desse cluster. 

1. Na seção **Configurações do banco de dados**, escolha **Editar** e **Editar grupo de parâmetros** para exibir a janela de grupos de parâmetros. 

1. Para o **Grupos de parâmetros** escolha o grupo de parâmetros **wlmtutorial** que você criou anteriormente. 

1. Selecione **Salvar alterações** para associar o grupo de parâmetros. 

   O cluster é modificado com o grupo de parâmetros. Contudo, você precisa reinicializar o cluster para que as alterações também sejam aplicadas ao banco de dados.

1. Escolha seu cluster e, em seguida, selecione **Reinicializar** para **Ações**. 

Depois que o cluster for reinicializado, seu status retornará para **Available (Disponível)**. 

## Seção 3: Rotear consultas para filas com base em grupos de usuários e grupos de consultas
<a name="tutorial-wlm-routing-queries-to-queues"></a>

Agora, o cluster está associado a um novo grupo de parâmetros e o WLM está configurado. Em seguida, execute algumas consultas para ver como o Amazon Redshift roteia as consultas em filas para processamento.

### Etapa 1: Visualizar a configuração da fila de consulta no banco de dados
<a name="tutorial-wlm-view-query-config"></a>

Primeiro, verifique se o banco de dados tem a configuração do WLM esperada.

#### Como visualizar a configuração da fila de consultas
<a name="how-to-wlm-view-query-config"></a>

1. Abra RSQL e execute a consulta a seguir. A consulta usa a visualização WLM\$1QUEUE\$1STATE\$1VW criada em [Etapa 1: Criar a visualização WLM\$1QUEUE\$1STATE\$1VW](#tutorial-wlm-create-queue-state-view). Se já tiver uma sessão conectada ao banco de dados antes da reinicialização do cluster, é necessário reconectar.

   ```
   select * from wlm_queue_state_vw;
   ```

   Este é um resultado de exemplo.

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

   Compare esses resultados com os resultados recebidos por você em [Etapa 1: Criar a visualização WLM\$1QUEUE\$1STATE\$1VW](#tutorial-wlm-create-queue-state-view). Observe que agora existem duas filas adicionais. Agora a fila 1 é a fila do grupo de consultas de teste, e a fila 2 é a fila do grupo de usuários administradores.

   Agora a fila 3 é a padrão. A última fila na lista sempre é a fila padrão. Essa é a fila para a qual consultas são roteadas por padrão caso nenhum grupo de usuários ou de consultas seja especificado em uma consulta.

1. Execute a consulta a seguir para confirmar que a consulta agora é executada na fila 3.

   ```
   select * from wlm_query_state_vw;
   ```

   Este é um resultado de exemplo.

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

### Etapa 2: Executar uma consulta usando a fila de grupos de consultas
<a name="tutorial-wlm-query-group"></a>

#### Como executar uma consulta usando a fila de grupos de consultas
<a name="how-to-wlm-query-group"></a>

1. Execute a consulta a seguir a fim de roteá-la para o grupo de consultas `test`.

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

1. Na outra janela RSQL, execute a consulta a seguir.

   ```
   select * from wlm_query_state_vw;
   ```

   Este é um resultado de exemplo.

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

   A consulta foi roteada para o grupo de consultas de teste, que é a fila 1 agora.

1. Selecione tudo na visualização de estado da fila.

   ```
   select * from wlm_queue_state_vw;
   ```

   Você verá um resultado semelhante ao seguinte.

   ```
   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. Agora redefina o grupo de consultas e reexecute a consulta longa:

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

1. Execute as consultas em relação às visualizações para ver os resultados.

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

   Estes são resultados de exemplo.

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

   O resultado deve ser a consulta em execução na fila 3 novamente.

### Etapa 3: Criar um grupo e um usuário de banco de dados
<a name="tutorial-wlm-create-db-user-and-group"></a>

Para executar todas as consultas nessa fila, você precisa criar o grupo de usuários no banco de dados e adicionar um usuário ao grupo. Depois, faça logon com o RSQL usando as credenciais do novo usuário e execute consultas. É necessário executar consultas como um superusuário, como usuário administrador, para criar usuários de banco de dados.

#### Como criar um usuário do banco de dados e um grupo de usuários
<a name="how-to-wlm-create-db-user-and-group"></a>

1. No banco de dados, crie um nome do usuário do banco de dados `adminwlm` executando o comando a seguir em uma janela RSQL.

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

1. Em seguida, execute os comandos a seguir para criar o novo grupo de usuários e adicionar o novo usuário `adminwlm` a ele.

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

### Etapa 4: Executar uma consulta usando a fila de grupos de usuários
<a name="tutorial-wlm-user-group-query"></a>

Na sequência, execute uma consulta e roteie-a para a fila do grupo de usuários. Você faz isso quando quiser rotear a consulta para uma fila configurada para processar o tipo de consulta que deseja executar.

#### Como executar uma consulta usando a fila de grupos de usuários
<a name="how-to-wlm-user-group-query"></a>

1. Na janela RSQL 2, execute as consultas a seguir a fim de alternar para a conta `adminwlm` e executar uma consulta desse usuário.

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

1. Na janela RSQL 1, execute a consulta a seguir para ver a fila de consultas para a qual as consultas são roteadas.

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

   Estes são resultados de exemplo.

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

   A fila em que essa consulta foi executada está na fila 2, a fila de usuários `admin`. Sempre que você executar consultas conectado como esse usuário, elas serão executadas na fila 2, a menos que especifique um grupo de consultas diferente a ser usado. A fila escolhida depende das regras de atribuição de fila. Para obter mais informações, consulte [Regras de atribuição de fila do WLM](cm-c-wlm-queue-assignment-rules.md). 

1. Agora execute a consulta a seguir na janela RSQL 2.

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

1. Na janela RSQL 1, execute a consulta a seguir para ver a fila de consultas para a qual as consultas são roteadas.

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

   Estes são resultados de exemplo.

   ```
   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. Quando terminar, redefina o grupo de consultas.

   ```
   reset query_group;
   ```

## Seção 4: Usar wlm\$1query\$1slot\$1count para substituir temporariamente o nível de simultaneidade em uma fila
<a name="tutorial-wlm-query-slot-count"></a>

Às vezes, os usuários podem precisar temporariamente de mais recursos para uma consulta específica. Em caso afirmativo, elas poderão usar a definição de configuração wlm\$1query\$1slot\$1count para substituir temporariamente a maneira como os slots são alocados em uma fila de consultas. *Slots* são unidades de memória e CPU usadas para processar consultas. Convém substituir a contagem de slots quando você tiver consultas ocasionais utilizando muitos recursos no cluster, como acontece quando você realiza uma operação VACUUM no banco de dados. 

Você poderá perceber que os usuários geralmente precisarão definir wlm\$1query\$1slot\$1count para determinados tipos de consultas. Se esse for o caso, considerar ajustar a configuração de WLM e conceder aos usuários uma fila mais adequada às necessidades de suas consultas. Para obter mais informações sobre como substituir temporariamente o nível de simultaneidade usando a contagem de slots, consulte [wlm\$1query\$1slot\$1count](r_wlm_query_slot_count.md).

### Etapa 1: Substituir o nível de simultaneidade usando wlm\$1query\$1slot\$1count
<a name="tutorial-wlm-override-slot-count"></a>

Para fins deste tutorial, executamos a mesma consulta SELECT demorada. Ela é executada como o usuário `adminwlm` utilizando wlm\$1query\$1slot\$1count para aumentar o número de slots disponíveis para a consulta.

#### Como substituir o nível de simultaneidade usando wlm\$1query\$1slot\$1count
<a name="how-to-wlm-override-slot-count"></a>

1. Aumente o limite na consulta para verificar se você tem tempo suficiente para consultar a visualização WLM\$1QUERY\$1STATE\$1VW e ver um resultado. 

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

1. Agora, consulte WLM\$1QUERY\$1STATE\$1VW com o usuário administrador para ver como a consulta está sendo executada.

   ```
   select * from wlm_query_state_vw;
   ```

   Este é um resultado de exemplo.

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

   A contagem de slots para a consulta é 3. Essa contagem significa que a consulta está usando todos os três slots para processar a consulta, alocando todos os recursos na fila para essa consulta.

1. Agora execute a consulta a seguir.

   ```
   select * from WLM_QUEUE_STATE_VW;
   ```

   Este é um resultado de exemplo.

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

   A definição de configuração wlm\$1query\$1slot\$1count é válida somente para a sessão atual. Se a sessão expirar, ou outro usuário executar uma consulta, a configuração do WLM será usada.

1. Redefina a contagem de slots e reexecute o teste.

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

   Estes são resultados de exemplo.

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

### Etapa 2: Executar consultas em sessões diferentes
<a name="tutorial-wlm-run-queries-from-different-sessions"></a>

Em seguida, execute consultas em sessões diferentes.

#### Como executar consultas em sessões diferentes
<a name="how-to-wlm-run-queries-from-different-sessions"></a>

1. Nas janelas RSQL 1 e 2, execute o seguinte para usar o grupo de consultas de teste.

   ```
   set query_group to test;
   ```

1. Na janela RSQL 1, execute a consulta demorada a seguir.

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

1. Enquanto a consulta demorada ainda estiver em execução na janela RSQL 1, execute o seguinte. Esses comandos aumentam a contagem de slots a fim de usar todos os slots para a fila e começa a executar a consulta demorada.

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

1. Abra uma terceira janela RSQL e consulte as visualizações para ver os resultados.

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

   Estes são resultados de exemplo.

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

   Observe que a primeira consulta usa um dos slots alocados à fila 1 para executar a consulta. Além disso, observe que há uma consulta que está aguardando na fila (onde `queued` é `1` e `state` é `QueuedWaiting`). Depois que a primeira consulta for concluída, a segunda será executada. Essa execução acontece porque ambas as consultas são roteadas para o grupo de consultas `test`, e a segunda consulta deve aguardar slots suficientes para começar o processamento.

## Seção 5: Limpar os recursos
<a name="tutorial-wlm-cleaning-up-resources"></a>

O cluster continua acumulando cobranças enquanto está em execução. Ao concluir este tutorial, retorne seu ambiente ao estado anterior seguindo as etapas em [Encontrar recursos adicionais e redefinir seu ambiente](https://docs.aws.amazon.com/redshift/latest/gsg/rs-gsg-clean-up-tasks.html) no *Guia de conceitos básicos do Amazon Redshift*.

Para obter mais informações sobre WLM, consulte [Gerenciamento do workload](cm-c-implementing-workload-management.md).