Ciclo de vida de uma query (SQL Server) - Parte 2

Fala galera, todos bem? Nesse post vou continuar a sequencia sobre o ciclo de vida de uma query no SQL Server. Estamos agora no segundo componente do processo. Você pode ver o primeiro post aqui.

Estamos navegando por essa imagem que mostra o processo que o SQL Server faz para processar uma query internamente.

Vamos tratar hoje sobre o Relational Engine - Command Parser.

Ele tem duas funções muito importantes e é aqui onde a a brincadeira começa a ficar interessante. Depois de receber o pacote de solicitação (comando a ser executado) o Command Parser confere se a sintaxe do comando esta correta e vai funcionar. Nesse momento ao identificar algo errado na escrita do comando T-SQL o processo é finalizado e um erro é retornado do banco de dados (Sintax error, quem ai nunca viu um desse pela frente?). Depois de garantir que a sintaxe do comando esta correta ele passa para a sua segunda função importante que é identificar se existe um plano de execução já gerado para aquela query no "Plan Cache".

Um plano de execução é como uma rota no waze ou maps, você informa onde quer chegar e o aplicativo traça a melhor rota, guardadas as devidas proporções, o plano de execução indica dentro do SQL Server como ele fará para chegar nos dados solicitados na query.

Como você já deve estar imaginando existe um custo para o SQL Server criar esse plano de execução, portanto ele armazena no plan cache o que já gerou para poder reaproveitar o que já foi criado ao invés de gerar novamente toda hora a mesma coisa. Cada query executada no banco o SQL Server gera um hash dela (identificador único), nesse caso o Command Parser procura pelo hash gerado da query no plan cache e se encontrar ele encaminha a solicitação de forma direta para o "Query Executor". Caso ele não encontre um plano já criado encaminha para o "Query Optimizer" que vai criar o plano de execução da query (assunto para o próximo post da serie).

Ilustrando no exemplo do restaurante (história iniciada no post 1) o Command parser vai atuar lá dentro da cozinha. O chefe da cozinha vai avaliar se o pedido deixado pelo garçom esta correto (com tudo que precisa, ponto da carne, por exemplo), com tudo certo ele passa o pedido para um dos cozinheiros que já sabe tem a receita do prato de cabeça (foi do command parser direto pro query executor), caso o pedido tivesse algo que os cozinheiros ainda não conhecessem bem (pedido especial para o filho de um amigo do dono do restaurante que ele não via a muito tempo hehe), precisaria que o chefe fosse criar o prato e mostrar a receita a eles para depois executarem (foi do command parser para o query optimizer).

No próximo post vamos avançar para a terceira etapa do processo!

Nos acompanhe em nossas redes sociais!

Grupo VIP Telegram: DBA On boarding

Youtube(vídeos novos todas as quartas): DBA On boarding

Face & Instagram(conteúdo diário): DBA On boarding

Até a próxima, tchau!

#comunidadebd