Artigos Banco de Dados Paralelismo no SQL Server

Por que eu devo ler este artigo:Este artigo tem por objetivo apresentar aspectos do funcionamento da engine do SQL Server no que toca a execução de consultas utilizando operadores paralelos, isto é, explorando hardwares que possuem diversos processadores.

O artigo será útil para o leitor entender os conceitos de paralelismo, analisar planos paralelos, conhecer detalhes do otimizador de consultas, determinar as corretas configurações de uma instância do SQL Server e, naturalmente, ganhar uma sólida base para aplicar em seu ambiente as melhores práticas, fazendo corretamente o troubleshooting ou tuning de consultas paralelas.

Vivemos um período onde os processadores não evoluem mais tão rapidamente a cada novo ciclo de lançamento dos fabricantes. Em contrapartida, encontramos cada vez mais processadores em uma única máquina. Diante disso, é necessário que os programas passem a explorar o paralelismo em seu código, com múltiplas threads em execução, potencializando o uso do hardware à sua disposição.

O paralelismo possui um objetivo muito nobre, que é explorar a concorrência de processamento em um programa com o objetivo de resolver um problema em menos tempo.

Porém, é importante frisar que isto não significa que o uso de recursos será menor, pelo contrário, o tempo total de processamento (uso efetivo das CPUs) tende a ser maior, pois além da execução é necessário incluir no código mecanismos de sincronização das threads.

Atualmente é comum encontrarmos instâncias do SQL Server em servidores com 16, 32 ou mais núcleos (cores) de processamento. Diante desse cenário, é desejável que a engine possa explorar o paralelismo em seu código, ainda mais considerando que o SQL Server é licenciado por núcleo e não por outros fatores como, por exemplo, quantidade de memória.

E mesmo que o código do SQL Server tenha diversos trechos multi-thread, muitos deles não podem ser vistos ou são transparentes para nós, “usuários”. No entanto, existe um deles, assunto cerne deste artigo, onde podemos ver claramente a utilização de múltiplos núcleos de processamento: os planos de execução que possuem operadores paralelos.

Plano de execução paralelo

Definimos um plano paralelo como aquele composto por operadores que exploram o paralelismo em sua árvore de execução. Neste contexto, um conjunto de operadores paralelos é o que determina o que chamamos de zona paralela.

As zonas existem pelo fato do plano de execução nunca ser 100% paralelo, pois sempre o último operador deve ser não paralelo (serial) para que a engine possa retornar os registros da consulta a partir de uma única thread, chamada de coordenadora.

Dito isso, como primeiro exemplo deste artigo, faremos a comparação entre a execução de duas consultas, uma serial e outra paralela, com o intuito de apresentar como são processados os registros em um plano com zona paralela.

O detalhamento de como interpretar um plano de execução e seus operadores está além do escopo do artigo, porém é importante que se tenha o conhecimento do que são e como podem ser gerados através do SQL Server Management Studio. Você encontra um artigo sobre planos de execução na edição 119 da SQL Magazine.

Na Listagem 1 demonstramos uma consulta simples, que conta a quantidade de registros na tabela dbo.bigTransactionHistory fazendo uso da hint “MAXDOP 1”, que força o SQL Server a não utilizar paralelismo para esta consulta. O termo MAXDOP é bastante adotado por ser uma redução de MAX Degree Of Parallelism, ou grau máximo de paralelismo, e também será empregado ao longo deste artigo.

Listagem 1. Consulta simples, sem paralelismo.


  USE AdventureWorks2012
  GO
   
  SET STATISTICS TIME ON;
  SELECT COUNT(*) FROM dbo.bigTransactionHistory OPTION (MAXDOP 1);
  GO

Como pode ser verificado na Figura 1, o plano de execução é simples. O SQL Server opta por percorrer um índice não cluster por completo (index scan), retornando cada um dos registros para ser contabilizado pelo próximo operador (stream aggregate), e por fim devolvendo o resultado para o cliente (o compute scalar não é relevante neste contexto).

Figura 1. Plano de execução simples, sem paralelismo.

Esse plano de execução tem um custo total de 150.456 e como saída gerada pelo comando SET STATISTICS TIME ON, t ...

Quer ler esse conteúdo completo? Tenha acesso completo