Crie um site como este com o WordPress.com
Comece agora

O curioso caso, onde o SQL não usou paralelismo.

Olá, pessoal! Tudo bem?

Hoje vim trazer um caso que encontrei no meu dia a dia, um tanto quanto curioso.

Havia uma query que tinha um tempo de execução de aproximadamente uma hora e não executava em paralelo, quando notei, claro, verifiquei alguns pontos como:

  • Maxdop;
  • Cost Threshold;
  • Utilização de funções (UDF);
  • Entre outros…

Incrível foi que mesmo ele atendendo todos os parâmetros necessários, inclusive utilizando o traceflag 8649 ou hint ENABLE_PARALLEL_PLAN_PREFERENCE a query continuava rodando em somente 1 thread.

Bem, na verdade, logo, descobri que ela atendia quase todos requisitos necessários para o uso do paralelismo. Vamos ver na prática?

Os scripts para simulação deste cenário estão no final do post, utilize-os somente em seu ambiente de testes.

A consulta abaixo, é somente ilustrativa.

Uma vez que a query acima ultrapassar o custo definido no Cost Threshold, junto com a utilização do Hint em destaque, atendendo “todos” os requisitos, enorme é a probabilidade que a query rode em paralelo, porém, como demonstrado abaixo, não é o que ocorre.

É aí que vem algo inusitado, depois de algum tempo no google, encontrei uma resposta do Paul White em que ele destaca um dos motivos: (Link no final do post)

É, infelizmente isto é verdade, na consulta anterior, não faço uso de nenhuma coluna computada, porém, na tabela pedido há uma coluna computada que utiliza uma UDF.

Para seguir com os testes, irei dropar a coluna computada que contem uma função UDF.

Como exibido abaixo, bastou remover a coluna que a consulta passou a rodar em paralelo.

Compartilhando uma solução para cenários que não é possível que a coluna seja alterada/removida:

Criação de view indexada.

OBS: Sim, eu poderia ter criado uma view indexada que atende-se tudo que a query precisava, porém, o intuito é só demonstrar que ao utilizar a view indexada a query voltaria rodar em paralelo.

Reescrita:

Dessa vez, a query passou rodar em paralelo. 😀

Alguns pontos de atenção:

  • O problema não é a coluna computada em si, o problema é a coluna computada + UDF;
  • Mesmo a UDF sendo determinística e criando a coluna com a clausula PERSISTED o plano continua executando em serial;
  • Indexar uma coluna computada + UDF não fará o plano executar em paralelo.

Já conhecia esse problema? Se sim, qual foi a solução aplicada? Ficarei feliz de saber como foi sua experiência sobre o caso.

Um abraço a todos, em especial ao Fabiano Lira (https://fabianolira.com.br/), que me ajudou encontrar o motivo pela qual a query não rodava em paralelo.

Mais sobre view indexada: https://vulgomarcio.home.blog/2019/07/29/utilizando-view-indexada-para-melhorar-a-performance-de-suas-consultas/

Referência: https://dba.stackexchange.com/questions/134453/sql-not-engaging-parallelism-for-extremely-large-query

Link para download da demo: https://github.com/Nusyc/WhyDidYouAvoidParallelism/

No script 1, está o conteúdo para criação do ambiente e no Script 2 os scripts utilizados nas imagens acima.

4 comentários em “O curioso caso, onde o SQL não usou paralelismo.

Adicione o seu

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s

Este site utiliza o Akismet para reduzir spam. Saiba como seus dados em comentários são processados.

Blog no WordPress.com.

Acima ↑

%d blogueiros gostam disto: