Arquitetura SQL Server

MS SQL Server é uma arquitetura cliente-servidor. O processo do MS SQL Server começa

com o aplicativo cliente enviando uma solicitação. O SQL Server aceita, processa e
responde à solicitação com os dados processados. Vamos discutir em detalhes toda a
arquitetura mostrada abaixo:

Como o diagrama abaixo descreve, existem três componentes principais na arquitetura do

SQL Server:

1. Camada de Protocolo
2. Mecanismo Relacional
3. Mecanismo de Armazenamento

Diagrama de arquitetura do SQL Server

Camada de protocolo - SNI
MS SQL SERVER PROTOCOL LAYER suporta 3 tipos de arquitetura cliente-
servidor. Começaremos com “ Três Tipos de Arquitetura Cliente-Servidor” que o MS
SQL Server suporta.

Memoria compartilhada
Vamos reconsiderar um cenário de conversa matinal.

MOM e TOM – Aqui Tom e sua mãe, estavam no mesmo lugar lógico, ou seja, em
casa. Tom conseguiu pedir café e mamãe serviu quente.

MS SQL SERVER – Aqui o servidor MS SQL fornece PROTOCOLO DE

MEMÓRIA COMPARTILHADA . Aqui, o CLIENTE e o servidor MS SQL são
executados na mesma máquina. Ambos podem se comunicar via protocolo de Memória
Compartilhada.

Analogia: Permite mapear entidades nos dois cenários acima. Podemos facilmente
mapear Tom para Cliente, Mãe para servidor SQL, Casa para Máquina e Comunicação
Verbal para Protocolo de Memória Compartilhada.

Da mesa de configuração e instalação:

Para conexão com o banco de dados local – no SQL Management Studio, a opção “Nome
do servidor” pode ser
“.”

"localhost"

“127.0.0.1”

“Máquina\Instância”

TCP/IP
Agora considere que à noite, Tom está no clima de festa. Ele quer um café encomendado
em uma cafeteria conhecida. A cafeteria está localizada a 10 km de sua casa.

Aqui, Tom e Starbuck estão em locais físicos diferentes. Tom em casa e Starbucks no
movimentado mercado. Eles estão se comunicando via rede celular. Da mesma forma,
MS SQL SERVER fornece a capacidade de interagir via protocolo TCP/IP, onde
CLIENT e MS SQL Server são remotos entre si e instalados em uma máquina separada.

Analogia: Permite mapear entidades nos dois cenários acima. Podemos mapear
facilmente o Tom para o cliente, o Starbuck para o servidor SQL, o local
doméstico/mercado para o local remoto e, finalmente, a rede celular para o protocolo
TCP/IP.

Notas da mesa de Configuração/instalação:

 No SQL Management Studio – Para conexão via TCP\IP, a opção “Nome do

servidor” deve ser “Máquina\Instância do servidor”.
 O servidor SQL usa a porta 1433 no TCP/IP.

Pipes nomeados
Agora, finalmente à noite, Tom queria tomar um chá verde claro que sua vizinha Sierra
preparava muito bem.
Aqui , Tom e sua vizinha , Sierra, estão no mesmo local físico , sendo vizinhos um do
outro. Eles estão se comunicando via rede Intra. Da mesma forma, o MS SQL
SERVER fornece a capacidade de interagir por meio do protocolo Named Pipe . Aqui o
CLIENT e o MS SQL SERVER estão conectados via LAN .

Analogia: Permite mapear entidades nos dois cenários acima. Podemos mapear
facilmente o Tom para o cliente, o Sierra para o servidor SQL, o vizinho para a LAN e,
finalmente, a rede Intra para o Named Pipe Protocol.

Notas da mesa de Configuração/instalação:

 Para conexão via pipe nomeado. Essa opção está desabilitada por padrão e
precisa ser habilitada pelo SQL Configuration Manager.

O que é TDS?
Agora que sabemos que existem três tipos de Arquitetura Cliente-Servidor, vamos dar
uma olhada no TDS:

 TDS significa Fluxo de Dados Tabulares.

 Todos os 3 protocolos usam pacotes TDS. O TDS é encapsulado em pacotes de
rede. Isso permite a transferência de dados da máquina cliente para a máquina
servidora.
 O TDS foi desenvolvido pela Sybase e agora pertence à Microsoft

Mecanismo Relacional
O Mecanismo Relacional também é conhecido como Processador de Consultas. Ele tem
os componentes do SQL Server que determinam exatamente o que uma consulta precisa
fazer e como ela pode ser feita da melhor maneira. Ele é responsável pela execução das
consultas do usuário solicitando dados do mecanismo de armazenamento e processando
os resultados que são retornados.

Conforme descrito no Diagrama de Arquitetura, existem 3 componentes principais do

Mecanismo Relacional. Vamos estudar os componentes em detalhes:

Analisador CMD
Os dados, uma vez recebidos da Camada de Protocolo, são passados para o Mecanismo
Relacional. O “CMD Parser” é o primeiro componente do Relational Engine a receber
os dados da Consulta. O principal trabalho do CMD Parser é verificar a consulta de erros
sintáticos e semânticos. Por fim, gera uma Query Tree . Vamos discutir em detalhes.
Verificação sintática:

 Como qualquer outra linguagem de programação, o MS SQL também possui um

conjunto predefinido de palavras-chave. Além disso, o SQL Server possui sua
própria gramática que o SQL Server entende.
 SELECT, INSERT, UPDATE e muitos outros pertencem às listas de palavras-
chave predefinidas do MS SQL.
 O analisador CMD faz a verificação sintática. Se a entrada dos usuários não seguir
essas regras de sintaxe ou gramática do idioma, ela retornará um erro.

Exemplo: digamos que um russo foi a um restaurante japonês. Ele pede fast food em
russo. Infelizmente, o garçom só entende japonês. Qual seria o resultado mais óbvio?

A resposta é - o garçom não consegue processar mais o pedido.

Não deve haver nenhum desvio na gramática ou linguagem que o servidor SQL aceita. Se
houver, o servidor SQL não poderá processá-lo e, portanto, retornará uma mensagem de
erro.

Aprenderemos mais sobre a consulta do MS SQL nos próximos tutoriais. No entanto,

considere abaixo a sintaxe de consulta mais básica como

SELECT * de <TABLE_NAME>;
Agora, para ter a percepção do que a sintática faz, digamos se o usuário executar a query
básica abaixo:

SELECR * de <TABLE_NAME>
Observe que, em vez de 'SELECT', o usuário digitou "SELECR".
Resultado: o analisador CMD analisará esta instrução e lançará a mensagem de
erro. Como “SELECR” não segue o nome e a gramática predefinidos da palavra-
chave. Aqui CMD Parser estava esperando “SELECT”.

Verificação semântica:

 Isso é executado pelo Normalizer .

 Em sua forma mais simples, ele verifica se o nome da coluna, o nome da tabela
que está sendo consultado existe no esquema. E se existir, vincule-o à
Consulta. Isso também é conhecido como Binding .
 A complexidade aumenta quando as consultas do usuário contêm VIEW. O
normalizador executa a substituição com a definição de exibição armazenada
internamente e muito mais.

Vamos entender isso com a ajuda do exemplo abaixo -

SELECT * de USER_ID
Resultado: O analisador CMD analisará esta instrução para verificação semântica. O
analisador lançará uma mensagem de erro, pois o Normalizer não encontrará a tabela
solicitada (USER_ID), pois ela não existe.

Criar árvore de consulta:

 Esta etapa gera diferentes árvores de execução nas quais a consulta pode ser
executada.
 Observe que todas as diferentes árvores têm a mesma saída desejada.

Otimizador
O trabalho do otimizador é criar um plano de execução para a consulta do usuário. Este é
o plano que determinará como a consulta do usuário será executada.

Observe que nem todas as consultas são otimizadas. A otimização é feita para comandos
DML (Data Modification Language) como SELECT, INSERT, DELETE e
UPDATE. Essas consultas são primeiro marcadas e depois enviadas para o
otimizador. Comandos DDL como CREATE e ALTER não são otimizados, mas são
compilados em um formulário interno. O custo da consulta é calculado com base em
fatores como uso de CPU, uso de memória e necessidades de entrada/saída.

A função do otimizador é encontrar o plano de execução mais barato, não o melhor e

com melhor custo-benefício.

Antes de entrarmos em mais detalhes técnicos do Optimizer, considere o exemplo da vida

real abaixo:
Exemplo:

Digamos que você queira abrir uma conta bancária online. Você já conhece um banco
que leva no máximo 2 dias para abrir uma conta. Mas, você também tem uma lista de 20
outros bancos, que podem ou não demorar menos de 2 dias. Você pode começar a se
envolver com esses bancos para determinar quais bancos levam menos de 2 dias. Agora,
você pode não encontrar um banco que demore menos de 2 dias, e há um tempo adicional
perdido devido à própria atividade de pesquisa. Teria sido melhor abrir uma conta no
próprio primeiro banco.

Conclusão: é mais importante selecionar sabiamente. Para ser preciso, escolha

qual opção é melhor, não a mais barata.

Da mesma forma, o MS SQL Optimizer funciona em algoritmos

exaustivos/heurísticos integrados. O objetivo é minimizar o tempo de execução da
consulta. Todos os algoritmos do Optimizer são propriedade da Microsoft e um
segredo. Embora , abaixo estão as etapas de alto nível executadas pelo MS SQL
Optimizer. As Buscas de Otimização seguem três fases conforme o diagrama abaixo:

Fase 0: Procurar Plano Trivial:

 Isso também é conhecido como estágio de pré-otimização .

 Em alguns casos, pode haver apenas um plano prático e viável, conhecido como
plano trivial. Não há necessidade de criar um plano otimizado. O motivo é que
pesquisar mais resultaria na localização do mesmo plano de execução de tempo de
execução. Isso também com o custo extra de pesquisa de plano otimizado, que não
era necessário.
 Se nenhum plano Trivial for encontrado, a 1ª Fase começa.
Fase 1: Pesquisar planos de processamento de transações

 Isso inclui a busca por Plano Simples e Complexo .

 Busca de Plano Simples: Os Dados Passados da coluna e Índice envolvidos na
Consulta, serão utilizados para Análise Estatística. Isso geralmente consiste, mas
não se restringe a um índice por tabela.
 Ainda assim, se o plano simples não for encontrado, o plano mais complexo será
pesquisado. Envolve Índice Múltiplo por tabela.

Fase 2: Processamento Paralelo e Otimização.

 Se nenhuma das estratégias acima funcionar, o Optimizer procura possibilidades

de processamento paralelo. Isso depende das capacidades de processamento e
configuração da Máquina.
 Se isso ainda não for possível, inicia-se a fase final de otimização. Agora, o
objetivo final da otimização é encontrar todas as outras opções possíveis para
executar a consulta da melhor maneira. Os algoritmos da fase final de otimização
são propriedade da Microsoft.

Executor de consulta
O executor de consulta chama o método de acesso. Ele fornece um plano de execução para
a lógica de busca de dados necessária para a execução. Depois que os dados são recebidos
do Storage Engine, o resultado é publicado na camada de protocolo. Finalmente, os dados
são enviados para o usuário final.

Mecanismo de Armazenamento

O trabalho do mecanismo de armazenamento é armazenar dados em um sistema de

armazenamento como disco ou SAN e recuperar os dados quando necessário. Antes de nos
aprofundarmos no mecanismo de armazenamento, vamos dar uma olhada em como os
dados são armazenados no banco de dados e os tipos de arquivos disponíveis.

Arquivo de dados e extensão:

Arquivo de Dados, armazena dados fisicamente na forma de páginas de dados, com cada
página de dados tendo um tamanho de 8KB, formando a menor unidade de armazenamento
no SQL Server. Essas páginas de dados são agrupadas logicamente para formar
extensões. Nenhum objeto é atribuído a uma página no SQL Server.

A manutenção do objeto é feita via extensões. A página tem uma seção chamada Cabeçalho
da página com um tamanho de 96 bytes, contendo as informações de metadados sobre a
página, como Tipo de página, Número da página, Tamanho do espaço usado, Tamanho do
espaço livre e Ponteiro para a próxima página e para a página anterior , etc
Tipos de arquivo

1. arquivo principal

 Cada banco de dados contém um arquivo Primário.

 Isso armazena todos os dados importantes relacionados a tabelas, visualizações,
gatilhos, etc.
 A extensão é . mdf geralmente, mas pode ser de qualquer extensão.

2. arquivo secundário

 O banco de dados pode ou não conter vários arquivos secundários.

 Isso é opcional e contém dados específicos do usuário.
 A extensão é . ndf geralmente, mas pode ter qualquer extensão.

3. Arquivo de log

 Também conhecido como registros de gravação antecipada.

 A extensão é . ldf
 Usado para gerenciamento de transações.
 Isso é usado para recuperar de quaisquer instâncias indesejadas. Execute a
importante tarefa de reversão para transações não confirmadas.

O mecanismo de armazenamento possui 3 componentes; vamos analisá-los em detalhes.

Método de acesso
Ele atua como uma interface entre o executor de consultas e o Buffer
Manager/Transaction Logs.

O método de acesso em si não faz nenhuma execução.

A primeira ação é determinar se a consulta é:

1. Selecionar declaração (DDL)

2. Declaração não selecionada (DDL e DML)

Dependendo do resultado, o Método de Acesso segue os seguintes passos:

1. Se a consulta for DDL , instrução SELECT, a consulta será passada para o Buffer
Manager para processamento posterior.
2. E se a consulta for DDL, instrução NON-SELECT , a consulta será passada para
o Gerenciador de transações. Isso inclui principalmente a instrução UPDATE.

Gerenciador de buffer
O gerenciador de buffer gerencia as principais funções dos módulos abaixo:

 Plano de Cache
 Análise de dados: cache de buffer e armazenamento de dados
 página suja

Aprenderemos o plano, o buffer e o cache de dados nesta seção. Abordaremos as páginas

sujas na seção Transação.
Plano de Cache

 Plano de Consulta Existente: O gerenciador de buffer verifica se o plano de

execução existe no Cache de Plano armazenado. Se Sim, o cache do plano de
consulta e seu cache de dados associado serão usados.
 Plano de cache de primeira vez: de onde vem o cache de plano existente? Se o
plano de execução de primeira consulta estiver sendo executado e for complexo, faz
sentido armazená-lo no cache de plano. Isso garantirá uma disponibilidade mais
rápida na próxima vez que o servidor SQL obtiver a mesma consulta. Portanto, nada
mais é do que a própria consulta de qual execução do Plano está sendo armazenada,
caso esteja sendo executada pela primeira vez.

Análise de dados: cache de buffer e armazenamento de dados

O gerenciador de buffer fornece acesso aos dados necessários. Abaixo, duas abordagens
são possíveis, dependendo se os dados existem ou não no cache de dados:

Buffer Cache – Análise Suave:

O Buffer Manager procura dados no buffer no cache de dados. Se presente, então esses
dados são usados pelo Query Executor. Isso melhora o desempenho, pois o número de
operações de E/S é reduzido ao buscar dados do cache em comparação com a busca de
dados do armazenamento de dados.
Armazenamento de Dados - Análise Difícil:

Se os dados não estiverem presentes no Buffer Manager, os dados necessários serão

pesquisados no armazenamento de dados. Se também armazena dados no cache de dados
para uso futuro.

página suja
Ele é armazenado como uma lógica de processamento do Transaction
Manager. Aprenderemos em detalhes na seção Gerenciador de transações.
Gerenciador de transações

O Transaction Manager é invocado quando o método de acesso determina que Query é

uma instrução Non-Select.

Gerenciador de registros

 O Log Manager mantém um registro de todas as atualizações feitas no sistema por

meio de logs em Transaction Logs.
 Os logs possuem Número de Sequência de Logs com o ID da Transação e
Registro de Modificação de Dados .
 Isso é usado para acompanhar a transação confirmada e a reversão da
transação .
Gerenciador de Bloqueio

 Durante a Transação, os dados associados no Armazenamento de Dados estão no

estado Bloqueado. Este processo é tratado pelo Lock Manager.
 Esse processo garante a consistência e o isolamento dos dados . Também
conhecidas como propriedades ACID.

Processo de Execução

 O Log Manager inicia o registro e o Lock Manager bloqueia os dados associados.

 A cópia dos dados é mantida no cache do Buffer.
 A cópia dos dados que deveriam ser atualizados é mantida no buffer de log e todos
os eventos atualizam os dados no buffer de dados.
 As páginas que armazenam os dados também são conhecidas como páginas
sujas .
 Checkpoint e Write-Ahead Logging: Este processo é executado e marca toda a
página de Dirty Pages to Disk, mas a página permanece no cache. A frequência é
de aproximadamente 1 execução por minuto. Mas a página é primeiro enviada
para a página de dados do arquivo de log do log do buffer. Isso é conhecido
como registro de gravação antecipada.
 Lazy Writer: A página suja pode permanecer na memória. Quando o servidor
SQL observa uma carga enorme e o buffer de memória é necessário para uma
nova transação, ele libera as páginas sujas do cache. Ele opera em LRU –
algoritmo menos usado recentemente para limpar a página do buffer pool para o
disco.

Resumo:

 Existem três tipos de arquitetura cliente-servidor: 1) Memória compartilhada 2)

TCP/IP 3) Pipes nomeados
 O TDS, desenvolvido pela Sybase e agora propriedade da Microsoft, é um pacote
encapsulado em pacotes de rede para transferência de dados da máquina cliente
para a máquina servidora.
 O Mecanismo Relacional contém três componentes principais: CMD Parser: É
responsável pelos erros sintáticos e semânticos e, finalmente, gera uma árvore de
consulta.

Otimizador: a função do otimizador é encontrar o plano de execução mais barato,

não o melhor e econômico.

Executor de consulta: o executor de consulta chama o método de acesso e

fornece um plano de execução para a lógica de busca de dados necessária para a
execução.

 Existem três tipos de arquivos Arquivo primário, arquivo secundário e arquivos de

log.
 Mecanismo de Armazenamento: Possui os seguintes componentes
importantes Método de Acesso: Este Componente Determina se a consulta é
Select ou Non-Select Statement. Invoca o Buffer e o Transfer Manager de acordo.

Buffer Manager: O gerenciador de buffer gerencia as funções principais para

Plan Cache, Data Parsing e Dirty Page.

Gerenciador de transações: gerencia transações não selecionadas com a ajuda de

gerenciadores de log e bloqueio. Além disso, facilita a implementação importante
do log Write Ahead e dos gravadores preguiçosos.