Entenda o ciclo de vida de uma Query no SQL Server: Parte 1

Tão importante quanto ter um modelo de troubleshooting desenhado, é entender o que levou a acontecer o incidente. Muito se pode entender do problema, olhando todos os pontos da execução da requisição, e esse é o intuito deste artigo: explorar todo o ciclo de vida de uma query. Entre a solicitação do usuário e a entrega do resultado, muita coisa acontece no SQL Server e é o que veremos a seguir.

Protocol Layer

Tudo começa quando um usuário envia uma solicitação via SNI( SQL Server Network Interface) ao banco de dados a partir de uma query, e aqui vamos utilizar o exemplo de uma instrução do tipo SELECT. Esta solicitação é encaminhada ao SBGD através de um protocolo denominado TDS (Tabular Data Stream) que fica responsável por “desembrulhar” este pacote no client e analisar o que está sendo solicitado. Este mesmo protocolo é o responsável por retornar o resultado ao solicitante ao fim da execução.

Relational Engine – Command Parser

O próximo componente é o Command Parser e é onde a “mágica” começa. Nesta camada, o SQL lida com eventos de T-SQL, analisando sua sintaxe e devolvendo caso haja quaisquer erros de volta à camada do solicitante. Com a sintaxe validada, o próximo passo é criar um plano de execução ou reaproveitar um plano ja existente no Plan Cache. Neste caso é criado uma hash do T-SQL para verificar nesta partição do Buffer Pool se há um plano adequado. se houver, a instrução é designada diretamente ao Query Executor, e falaremos mais sobre ele logo abaixo.

Relational Engine – Query Optimizer

“Beleza, mas e se não houver um plano adequado para a solicitação?”, Neste caso o CMD Parser gerará uma árvore de consulta baseado no T-SQL e enviará à camada do Query Optimizer. Esta camada é uma das mais complexas e “misteriosas” do SQL Server. ele avalia a árvore baseando-se em custos e o objetivo é encontrar o plano mais eficiente, ou seja, um plano que terá o menor custo de execução. Em um plano, cada operador tem um custo de linha de base, que é então multiplicado pelo tamanho da linha e pelo número estimado de linhas para obter o custo desse operador — e o custo do plano é o custo total de todos os operadores. Este “Custo” é apenas um número arbitrário utilizado para representar o custo de recurso do plano em questão.

Esta otimização ocorre em 3 fases e são elas:

• Fase 0 — Durante esta fase, o otimizador analisa os NESTED LOOP JOINS e não considerará operadores de paralelismo. O otimizador vai parar aqui se o custo do plano que encontrou for < 0.2. Um plano gerado nesta fase é conhecido como um processo de transação, ou TRIVIAL PLAN (Plano Trivial).
• Fase 1 — A Fase 1 usa um subconjunto das possíveis regras de otimização e procura padrões comuns para os quais já possui um plano. O otimizador vai parar aqui se o custo do plano que encontrou for < 1.0. Planos gerados nesta fase são chamados de QUICK PLAN (planos rápidos).
• Fase 2 — Esta fase final é onde o otimizador puxa todas as paradas e é capaz de usar todas as suas regras de otimização. Ele também olha para o paralelismo e as visualizações indexadas (se você estiver executando a Enterprise Edition) – FULL PLAN (otimização TOTAL).

Relational Engine – Query Executor

E assim chegamos ao Query Executor. Este componente é o responsável por de fato executar a query, trabalhando por cada etapa do plano e devolvendo o resultado ao usuário. Nesta parte do ciclo, há uma interação com o mecanismo de armazenamento para recuperar ou modificar dados. E nesta parte há diferenças entre instruções DML e DDL. Iremos explorar esta diferença no próximo artigo com mais detalhes.

Com isso, chegamos ao fim deste artigo. Espero que tenham gostado e nos vemos no próximo capitulo.

Por Igor Paixao

• banco de dados

Entenda o ciclo de vida de uma Query no SQL Server

Fique atento ao nosso próximo artigo para entender melhor as diferenças entre DML e DDL! Não perca a oportunidade de aprofundar seu conhecimento sobre o funcionamento das queries e otimizar suas operações de dados.

Data Engineering