Olá, pessoal, hoje vamos conhecer um pouco como é a nossa jornada pelo ciclo de vida de uma query e as suas etapas, as quais explicaremos de uma forma resumida.

1-SQL Server Network Interface:
É responsável pela comunicação entre o cliente e o servidor. Suporta alguns tipos de protocolos: Shared Memory, TCP/IP, Named Pipes e VIA.

Após a conexão ser estabelecida, é criado uma conexão segura para o TDS o qual é utilizado para enviar e receber os dados.

2-Tabular Data Stream (TDS):
Ponto de comunicação entre o cliente e o servidor. Existe um endpoint para cada protocolo de rede e um reservado especificamente para o DAC.

3-Protocol Layer:
Camada de protocolo que recebe o pacote do TDS, enviado através do SQL Server Network Interface (SNI). Além disso necessita desempacotar a solicitação no cliente e analisar a solicitação do usuário.

Vale ressaltar, que esse mesmo protocolo é responsável pelo retorno das informações ao usuário.

4-Relational Engine:
Aqui o comando enviado pelo usuário passa por algumas fases, onde o objetivo é validar o código, criar ou utilizar um plano de execução existente com o objetivo de uma melhor performance.
Descrevemos abaixo as etapas:

Command Parser:
Nessa etapa, é verificado a sintaxe enviada pelo usuário através do Protocol Layer, onde no caso de erro, retorna ao usuário e, no caso de ser uma sintaxe válida, a próxima etapa será criar um plano de execução (Query Optimizer) ou reaproveitar um plano já existente no Plan Cache. Para verificar por um plano de execução, é criado um hash que será utilizado para verificar a existência no Buffer Pool, caso exista, ele irá direto para o Query Executor.

Plan Cache:
Parte do Buffer pool utilizado para armazenar os planos de execução em caso de serem reutilizados posteriormente.

Não havendo um plano de execução, o command parser gerará uma Query Tree baseada na consulta, onde ela será avaliada levando-se em conta os custos e assim, encontrar um plano mais eficiente. O custo do plano é o custo total de todos os operadores.

Query Optmizer:
O principal objetivo é encontrar o plano mais eficiente para determinada consulta, ou seja, encontrar um serviço de execução em razão do tempo ao invés do melhor, todo tempo, que seria uma operação custosa.

Após encontrar um bom plano, é iniciado o primeiro processo de pré-otimização:

• Simplification:
  Transforma a Query Tree em uma forma que simplifica ainda mais o processo de otimização. Remove as contradições, trabalha com os joins, escolhe a ordem do join inicial levando em conta as estatísticas e cardinalidade;
• Query Optmizer:
  Ao finalizar a fase Simplification, é verificado se existe um Trivial Plan, isso se dá quando uma consulta tem somente um plano disponível ou quando a escolha do plano é óbvia.
• Trivial Plan Search:
  Ao finalizar a fase Simplification, é verificado se existe um Trivial Plan, isso se dá quando uma consulta tem somente um plano disponível ou quando a escolha do plano é óbvia.
• Statistics Update:
  Caso não seja um Trivial Plan, é verificado se alguma estatística atualizada de modo automático está desatualizado e dispara a atualização dela. Caso seja necessária a atualização, o Query Optimizer aguardará a atualização das estatísticas, que por padrão são realizadas de forma síncrona.
• Phase 0:
  Nessa fase é analisado os Nested Loop Joins sem considerar os operadores de paralelismo. Caso o custo encontrado for < 0.2 o otimizador irá parar. Nessa fase o plano gerado é chamado de Trivial Plan;
• Phase 1:
  Nessa fase é utilizado um subconjunto das possíveis regras de otimização e procura por padrões comuns. Caso o custo encontrado for < 1.0 o otimizador irá parar. Os planos gerados são chamados de Quick Plan.
• Phase 2:
  Trata-se da fase final, onde o otimizador extrai todas as paradas usando todas as regras de otimização, assim como é analisado o paralelismo e as views indexadas. Nessa fase os planos gerados são chamados de Full Plan.
• Query Executor:
  Executa o plano de consulta trabalhando em cada etapa e interagindo com o Storage Engine para retornar ou modificar os dados utilizando uma interface OLEDB para o Acess Methods.

5-Storage Engine:
Access Methods:
Fornece as estruturas de armazenamento de dados e índices, assim como a interface pelas quais os dados são modificados e recuperados. Armazena as operações de linha, índices, alocação de páginas e versionamento. Mesmo com todo o código da solicitação, não executa nada, passando para o Buffer Manager essa responsabilidade.

Buffer Manager:
Responsável por toda parte de recebimento, armazenamento e entrega dos dados. Caso a leitura de algumas linhas seja solicitada, será verificado na página de dados que está no cache, se não existir, irá buscar no disco, armazenará o resultado no cache e somente então devolve para o Access Methods.

Tem a responsabilidade de gerenciar I/O de disco quando necessita trazer páginas de dados e índices para o cache, garantir que o Transaction Log seja escrito antes de cada alteração no banco seja executada.

Data Cache:
A maior parte do Buffer Pool, onde todas as páginas de dados lidas do disco são gravadas antes da utilização pelo usuário. O tempo de permanência das páginas em memória é determinado pela política Last Recently Used (LRU).

Transaction Manager:
Responsável por gerenciar a concorrência dos dados através dos locks (Lock Manager) e armazenar o log das transações no logfile (Log Manager).

Bom, por hoje era isso pessoal, espero que vocês tenham gostado de conhecer o ciclo de vida de uma query no SQL Server.

Nos vemos no próximo post!
Abraço!