Usar a visualização SVL_QUERY_SUMMARY - Amazon Redshift

Usar a visualização SVL_QUERY_SUMMARY

Para analisar as informações de resumo de consulta por fluxo usando SVL_QUERY_SUMMARY, faça o seguinte:

  1. Execute a seguinte consulta para determinar o ID de sua consulta:

    select query, elapsed, substring
from svl_qlog
order by query
desc limit 5;

    Examine o texto truncado da consulta no campo substring para determinar qual valor de query representa a sua consulta. Se você executou a consulta mais de uma vez, use o valor de query da linha com o menor valor elapsed. Esta é a linha para a versão compilada. Se você estiver executando várias consultas, poderá aumentar o valor usado pela cláusula LIMIT usada para certificar-se de que sua consulta seja incluída.

  2. Selecione linhas do SVL_QUERY_SUMMARY para sua consulta. Classifique os resultados por fluxo, segmento e etapa:

    select * from svl_query_summary where query = MyQueryID order by stm, seg, step;

    Este é um resultado de exemplo.

    Um exemplo de resultado para as linhas em SVL_QUERY_SUMMARY que correspondem a determinada consulta.

  3. Mapeie as etapas às operações de consulta no plano de consulta usando as informações em Mapeamento do plano de consulta para o resumo da consulta. Elas devem ter aproximadamente os mesmos valores para linhas e bytes (linhas * largura do plano de consulta). Se elas não tiverem, consulte Estatísticas de tabela ausentes ou desatualizadas para as soluções recomendadas.

  4. Verifique se o campo is_diskbased tem um valor de t (verdadeiro) para qualquer etapa. Os hash, agregados e classificações são operadores que provavelmente irão gravar dados em disco se o sistema não tiver memória suficiente alocada para o processamento de consulta.

    Se is_diskbased for verdadeiro, consulte Memória insuficiente alocada para a consulta para as soluções recomendadas.

  5. Revise os valores do campo label e verifique se há uma sequência AGG-DIST-AGG em qualquer lugar das etapas. Sua presença indica a agregação em duas etapas, que é cara. Para corrigir isso, altere a cláusula GROUP BY para usar a chave de distribuição (a primeira chave, se houver várias).

  6. Revise o valor de maxtime para cada segmento (ele é o mesmo para todas as etapas no segmento). Identifique um segmento com o maior valor de maxtime e analise as etapas neste segmento quanto aos operadores a seguir.

    nota

    Um valor maxtime alto não necessariamente indica um problema com o segmento. Independente de um valor alto, o segmento pode não ter levado muito tempo para processar. Todos os segmentos em um fluxo começam a ser cronometrados simultaneamente. No entanto, alguns segmentos downstream podem não ser executados até obterem dados dos segmentos upstream. Este efeito pode fazer parecer que eles tenham levado muito tempo, pois seus valores de maxtime incluirão tanto seu tempo de espera quanto o tempo de processamento.

    • BCAST ou DIST: nesses casos, o valor maxtime alto pode ser o resultado da redistribuição de um grande número linhas. Para soluções recomendadas, consulte Distribuição de dados pouco satisfatória.

    • HJOIN (junção hash): Se a etapa em questão tem um valor muito elevado no campo de rows em comparação ao valor de rows na etapa final do RETURN da consulta, consulte Junção de hash para as soluções recomendadas.

    • SCAN/SORT: procura uma sequência de etapas SCAN, SORT, SCAN, MERGE imediatamente antes de uma etapa de junção. Este padrão indica que os dados não classificados estão sendo varridos e, então, mesclados com a área classificada da tabela.

      Verifique se o valor de linhas para a etapa SCAN tem um valor muito alto em comparação ao valor de linhas na etapa final de RETURN da consulta. Este padrão indica que o mecanismo de execução está fazendo a varredura de linhas que serão posteriormente rejeitadas, o que é ineficiente. Para soluções recomendadas, consulte Predicado insuficientemente restritivo.

      Se o valor de maxtime para etapa SCAN é alto, consulte Cláusula WHERE pouco satisfatória para as soluções recomendadas.

      Se o valor de rows para a etapa SORT não for zero, consulte Linhas não classificadas ou mal classificadas para as soluções recomendadas.

  7. Revise os valores de rows e bytes para as etapas de 5 a 10 que precedem a etapa final RETURN para ter uma ideia da quantidade de dados que foi retornada ao cliente. Esse processo pode ser um tipo de arte.

    Por exemplo, no resumo de consulta de amostra a seguir, a terceira etapa de PROJECT fornece um valor de rows, mas não um valor de bytes. Ao examinarmos as etapas anteriores para encontrar uma etapa com o mesmo valor de rows, encontramos a etapa SCAN, que fornece informações tanto de linha quanto de bytes:

    Veja a seguir um resultado de exemplo.

    Uma linha nos resultados de resumo da consulta que é uma etapa SCAN com informações de linhas e bytes.

    Se você estiver retornando um volume de dados inusitadamente alto, consulte Conjunto de resultados muito grande para as soluções recomendadas.

  8. Verifique se o valor de bytes é alto em relação ao valor de rows para qualquer etapa, em comparação a outras etapas. Este padrão pode indicar que você está selecionando muitas colunas. Para soluções recomendadas, consulte Lista SELECT grande.