Administração de banco de dados II

Prévia do material em texto

Administração de Banco de Dados II 
Aula 1: Introdução ao SQL Server
Apresentação
Esta primeira aula da disciplina Administração de Bancos de Dados II é uma introdução ao Microsoft SQL Server, um dos
sistemas gerenciadores de bancos de dados (SGBDs) líderes do mercado.
Estudaremos as principais funcionalidades desenvolvidas pela Microsoft ao longo do tempo, as quais transformaram o
SQL Server de um SGBD Relacional em uma plataforma completa de serviços de dados.
Aprenderemos a administrar o Microsoft SQL Server, ou seja, entenderemos os conceitos e técnicas para utilizarmos suas
ferramentas de administração e garantirmos sua disponibilidade, segurança e desempenho.
Objetivos
Identi�car as principais características do Microsoft SQL Server;
Apontar as principais versões do produto disponibilizadas ao longo de sua evolução, suas inovações e as restrições
para a migração entre elas;
Descrever os modelos de licenciamento do SQL Server e para quais cenários cada um deles é mais indicado.
Conhecendo o SQL Server
O SQL Server é um Sistema Gerenciador de Bancos de Dados (SGBD) desenvolvido pela Microsoft. É, atualmente, um dos
líderes desse segmento de mercado, sendo utilizado em todos os tipos de empresas, desde as de menor porte até as de muito
grande porte.
Saiba mais
Vale a pena conferir os rankings publicados regularmente em sites de pesquisa, como o DB-Engines ranking.
javascript:void(0);
Iniciaremos este estudo pela instalação e pela con�guração básica do produto, pois há decisões bastante importantes já nessa
etapa. Vamos passar pela criação dos bancos de dados propriamente ditos, incluindo as tabelas, as restrições (constraints), as
visões e os procedimentos armazenados (stored procedures), aprender a fazer backup e restore e con�gurar a segurança do
banco de dados.
Em seguida, exploraremos o dia a dia de um administrador de banco de dados: A monitoração. É onde podemos ver o que está
acontecendo no momento, os processos que estão em execução, as sessões dos usuários, quais processos estão executando
normalmente e quais estão aguardando um recurso bloqueado, quais são os bloqueios, os tempos de espera etc. Todas essas
informações são insumos para o trabalho do administrador.
De acordo com os sintomas e os comportamentos observados, utiliza-se a técnica e a ferramenta mais adequadas para
resolver os impasses provocados pelo curso normal de execuções de consultas e atualizações simultâneas em um banco de
dados.
Algumas dessas técnicas formam um conjunto de práticas que são um deleite para todo administrador de banco de dados: O
tuning, ou sintonia �na. Entenderemos como o otimizador do SGBD executa uma consulta e aprenderemos a ler um plano de
execução. Dependendo das conclusões, aplicaremos técnicas para melhorar o desempenho da consulta e, de uma forma mais
ampla, da carga de trabalho.
Por falar em usuários: Eles devem ser ouvidos! Eles podem perceber um
problema antes mesmo de nós. Uma lentidão em um sistema, um erro em
uma stored procedure ou até mesmo a indisponibilidade de todo o SGBD
podem ser observados primeiro pelos usuários. Eles podem ter dicas
importantes que levarão à causa raiz e à solução mais rapidamente. Com
tempo e dedicação, é possível aprender a fazer as perguntas certas!
 Principais características
 Clique no botão acima.
Principais características
O Microsoft SQL Server é um SGBD Relacional, isto é, implementa o Modelo Relacional para a representação de
conjuntos de dados como relações. Essa implementação ocorre na forma de funcionalidades para a criação de tabelas
e os relacionamentos entre elas, sendo também responsável pela execução de consultas sobre esses objetos. As
principais características são:
Pode ser instalado em máquinas físicas (baremetal), máquinas virtuais e containers, sobre sistemas operacionais
Windows e Linux;
Implementa um gerenciamento completo de processos e memória, de forma a maximizar a utilização de
recursos do servidor;
Implementa um gerenciamento das transações e do processamento das consultas, de maneira que o SGBD
possa ter um controle total sobre as operações executadas no banco de dados;
Permite capturar a carga de trabalho submetida ao banco de dados para monitorar os processos e usuários
deste, observar as consultas e atualizações solicitadas e veri�car os tempos de execução dessas operações;
Possui um otimizador que tem a �nalidade de gerar os planos de execução das consultas, garantindo que estas
sejam executadas de acordo com os recursos disponíveis, tanto do servidor em que está hospedado, quanto do
próprio database;
Permite conectar diversas instalações do SQL Server e, por meio dessas conexões, transferir dados de uma
instalação para outra, e ainda processar consultas em diversas instalações simultaneamente;
Utiliza a linguagem SQL padrão ANSI para que desenvolvedores e administradores possam criar os próprios
procedimentos e funções, mas também estende essa linguagem com especi�cações próprias, criando um dialeto
SQL denominado Transact-SQL;
Fornece uma interface padrão para desenvolvedores e administradores, o SQL Server Management Studio. Por
meio dela se pode executar a maioria das tarefas;
Oferece suporte a dados semiestruturados e não estruturados, como XML e JSON;
Possui diversas ferramentas, como um agendador de tarefas, uma ferramenta para implementação de work�ows
ETL (Extract, Transform and Load) e outra para desenvolvimento de soluções de Data Warehouse;
 Possibilita a integração do SQL com outras linguagens, como C#, R e Python, fornecendo uma base sólida para a
execução de implementações de Machine Learning e Big Data.
Diante de todas essas características é preciso observar algo fundamental: O Microsoft SQL Server não é
somente um SGBD Relacional. Ele estende a plataforma rumo a outros tipos de bancos de dados para dar
suporte, por exemplo, a Data Science e a Machine Learning, e ainda oferece uma série de outras ferramentas que
complementam o trabalho necessário no universo de administração e disponibilização de dados.
Propriedades ACID
No contexto de um Banco de Dados Relacional, o SQL Server garante as propriedades ACID, a saber: Atomicidade, Consistência,
Isolamento e Durabilidade. Partiremos dessas propriedades para avançarmos na compreensão das características principais
do SQL Server.
Clique nos botões para ver as informações.
É a propriedade que garante que toda operação no banco de dados é atômica, ou seja, ou ela é executada completamente
ou não é executada. A implementação que garante a atomicidade parte da transação. Quando um desenvolvedor inicia
uma transação com um BEGIN TRANSACTION e termina com COMMIT TRANSACTION ou ROLLBACK, o que ele está
fazendo é de�nir as operações que devem ser tratadas de forma atômica. Assim, ou todas elas serão executadas
completamente no banco de dados, ou nenhuma delas o será.
Atomicidade 
O SQL Server também garante a consistência, isto é, nenhuma transação pode violar as regras de integridade de�nidas no
esquema para a criação de objetos, como os relacionamentos entre tabelas e índices. Se um código tentar infringir
qualquer uma das restrições de�nidas nas colunas das tabelas e nas relações entre elas, o SQL Server não vai permitir e
vai emitir uma mensagem de erro. O desenvolvedor deverá garantir, então, que o erro seja tratado adequadamente e que a
transação seja desfeita por meio de um ROLLBACK.
Consistência 
De volta ao contexto do gerenciamento de transações, temos o conceito de isolamento. Ele garante a não interferência
entre as transações que estão em execução no mesmo momento. Imagine a quantidade de transações simultâneas em
um sistema bancário, por exemplo. O SQL Server garante que elas sejam executadas isoladamente umas das outras e
permite ao administrador controlar o nível de isolamento (isolation level) entre elas. Detalharemos esses níveis na aula de
Gerenciamento de Processos no SQL Server.
Isolamento 
Garante que a efetivação de uma transação, por meio de um COMMIT, seja de fato gravada em disco.Para isso, o SQL
Server registra todas as transações em um arquivo de log, de forma que, se houver uma falha no servidor que o impeça de
persistir os dados da transação, elas sejam recuperadas e persistidas após a recuperação do servidor.
Durabilidade 
Uma recomendação prática, no escopo das principais características do SQL Server, sobre o dialeto SQL disponível no SGBD,
chamado Transact-SQL, ou T-SQL, baseado no SQL Server padrão ANSI, inclui uma série de funções e construções que não
fazem parte da linguagem SQL padrão. É importante ter isso em mente porque se pretendemos que os procedimentos SQL
sejam compatíveis com outros SGBDs, então é recomendado que não se utilizem sintaxes proprietárias implementadas no T-
SQL.
Histórico da evolução
Conta a história do Microsoft SQL Server que ele foi orginalmente criado a partir de uma parceria entre a Microsoft e a Sybase.
A parceria tinha como objetivo portar o Sybase SQL Server para o sistema operacional OS/2, desenvolvido em conjunto com a
IBM. A primeira versão foi lançada em 1989.
A Microsoft então ingressou no mercado de Sistemas Gerenciadores de Bancos de Dados e começou a investir fortemente na
evolução de uma versão proprietária. A primeira versão de fato escrita pela Microsoft foi a versão 7.0, em 1998, e logo na
sequência a versão 2000.
Iniciaremos por essa versão. É muito importante que se observe a evolução das versões e das suas características porque a
maioria dos conceitos, técnicas e ferramentas estão presentes atualmente. Note também que as listas de características e
inovações apresentadas não são exaustivas.
SQL Server 2000
Esta versão, lançada no ano 2000, já contava com um mecanismo robusto para gerenciamento de bancos de dados. As
versões anteriores já tinham evoluído bastante a parte central do SGBD, chamado Database Engine, e tanto desenvolvedores
quanto administradores contavam com uma plataforma bastante con�ável para manutenção e administração de bancos de
dados relacionais.
 Em termos de popularidade, o SQL Server 2000 foi a primeira grande versão do produto. Consagrou-se por implementar
conceitos e ferramentas que fazem parte do produto até hoje. Uma inovação especialmente importante para administradores
foi a possibilidade de se executar mais de uma instância na mesma máquina.
As instâncias SQL Server que instaladas em uma máquina podem ser de versões diferentes, pois cada uma é totalmente
independente da outra, tendo o seu conjunto de recursos próprios, bancos de dados, usuários, regras de segurança etc.
https://estacio.webaula.com.br/cursos/go0410/aula1.html
Consolida-se então uma característica especialmente importante do SQL Server: Um servidor pode conter diversas instâncias
SQL Server e cada instância pode conter diversos bancos de dados. Por sua vez, cada banco de dados contém esquemas,
tabelas, visões, usuários, procedimentos e funções.
Atenção
O conceito de instâncias e bancos de dados é apresentado aqui especi�camente para o SQL Server, e pode ser diferente para
outros SGBDs.
Os administradores festejaram também grandes melhorias quanto à replicação de dados. Entre elas, O SQL Server 2000
passou a contar com o Log Shipping, uma técnica de cópia dos backups dos arquivos de log das transações para replicar
dados de um banco de dados para outro. Assim você poderia manter um banco de réplica somente para leitura a ser utilizado
em caso de falha no banco principal. Veremos os detalhes do Log Shipping na aula de Alta Disponibilidade e Recuperação de
Desastres.
Para os desenvolvedores, o dialeto Transact-SQL passou a contar com novas funcionalidades. Entre as mais importantes,
podemos citar:
Variáveis do tipo tabela
Além das tabelas temporárias, o
SQL Server passou a contar com
variáveis do tipo tabela.
Continue lendo...
Trigger do tipo instead-
of
Além da trigger do tipo after, o SQL
Server recebeu a implementação
do tipo instead-of, extremamente
útil em alguns casos.
Continue lendo...
Visões indexadas
As visões indexadas no SQL Server
são visões materializadas, isto é,
visões persistidas no banco de
dados.
Continue lendo...
Além das inovações técnicas, a Microsoft começava também a oferecer um novo conjunto de ferramentas adicionais ao
produto. Dentre elas, duas se destacaram especialmente e continuam a integrar o produto em suas versões mais recentes:
SQL Server Analysis Services (SSAS)
É a plataforma de serviços OLAP do SQL Server. Passou a oferecer as ferramentas de desenvolvimento e consumo de
dados para Data Warehouse, consistindo na principal abordagem da Microsoft para o mercado de Business Intelligence.
SQL Server Integration Services (SSIS)
É a ferramenta de ETL (Extract, Transform and Load) do SQL Server. Nela são criados os �uxos de trabalho que transferem
dados de um banco de dados para outro. No mundo atual, esses �uxos desempenham papel fundamental para as
aplicações, transportando grandes volumes de informação entre os diversos sistemas, internos ou externos a uma
organização.
SQL Server 2005
Uma importante estreia na versão 2005 foi o SQL Server Management Studio (SSMS), substituto do Enterprise Manager e do
Query Analyzer, as IDEs do SQL Server até a versão 2000. O SSMS continua sendo a principal IDE até hoje.
Para os desenvolvedores, uma extensa lista de melhorias incluiu novos tipos de dados, integração com CLR, suporte a XML e
nova implementação para CTEs:
https://estacio.webaula.com.br/cursos/go0410/aula1.html
https://estacio.webaula.com.br/cursos/go0410/aula1.html
https://estacio.webaula.com.br/cursos/go0410/aula1.html
Clique nos botões para ver as informações.
 Novos tipos de dados foram implementados na versão 2005 para aumentar os limites impostos pela versão 2000. As
colunas varchar, por exemplo, tinham o limite de 8000 bytes.
 Os novos tipos max aumentaram bastante esse limite. O tipo varchar(max) passou a aceitar até 2 bytes. Isto,
combinado com a remoção do limite para o tamanho da linha, melhorou sensivelmente os recursos para armazenamento
de dados.
varchar(max) e varbinary(max) 
31
 A versão 2000 trouxe signi�cativas melhorias na exposição ao CLR (Common Language Runtime) para integração de
código SQL com código escrito em outras linguagens .NET, como Visual Basic .NET e C#. Isso trouxe a possibilidade de se
utilizar linguagens compiladas para implementação de algoritmos nestas linguagens e sua integração com
procedimentos armazenados e funções.
 Um caso de uso bastante comum nesses cenários é a implementação de funções de criptogra�a em C# para uso em
senhas de usuários de aplicação e armazenamento no banco de dados.
CLR (common language runtime) 
 A linguagem XQuery para consulta em strings XML passou a permitir uma série de operações como recuperar um
conjunto de nós, recuperar o valor de um elemento especí�co ou ainda alterar o valor de um elemento.
Suporte a XML 
 Um recurso extremamente poderoso para desenvolvedores. Por meio de expressões CTE é possível criar uma query
temporária e sobre ela executar queries recursivas. É uma construção elegante que substitui construções mais
complexas, com desempenho ainda melhor.
CTE (common table expressions) 
SQL Server 2008 e 2008 R2
A versão 2008 também trouxe uma série de inovações. Em 2010 a Microsoft lançou a versão 2008 R2 trazendo melhorias nas
inovações apresentadas pela versão 2008. Esta foi uma versão consagrada do SQL Server, ainda em uso em sistemas
produtivos atualmente.
Essas versões trouxeram novidades especialmente úteis tanto para administradores quanto para desenvolvedores, como uma
nova ferramenta de administração de recursos, novos tipos de dados para localização geográ�ca, compressão de bancos de
dados transparente para aplicações e novo algoritmo de criptogra�a aplicado a dados gravados.
Resource governor
Com a possibilidade de execução de várias instâncias em um mesmo servidor, tornou-se necessário estabelecer alguns
tipos de limites para processos em execução, de forma que um processo com uso intensivo de entrada/saída não
impactasse outros processos. Veremos maisdetalhes sobre essa funcionalidade na aula de Instalação e Con�guração. 
 
CDC (change data capture)
Funcionalidade para auditoria de operações em bancos de dados extremamente útil. Com ela é possível, por exemplo,
habilitar a captura de operações em uma tabela e registrar (em um esquema especí�co para isso) as alterações realizadas
nas linhas dessa tabela. Veremos mais detalhes sobre essa funcionalidade na aula de Segurança e Auditoria. 
 
Novos tipos de dados
A versão 2008 trouxe novos tipos de dados especi�camente para uso em coordenadas espaciais, tanto para coordenadas
geométricas (plano cartesiano) quanto para coordenadas geográ�cas (latitude e longitude), além de funcionalidades para a
utilização desses tipos na geração de objetos espaciais, como retas, polígonos e mapas. 
 
Coluna FILESTREAM
Até as versões anteriores, imagens e documentos eram armazenados como bitstreams em colunas do tipo BLOB (Binary
Large Objects). Com o FILESTREAM, esses arquivos passaram a ser armazenados no �lesystem, sendo referenciados
pelas colunas e parte integrante do banco de dados. 
 
Compressão de dados
Inicialmente apresentado como um recurso para a diminuição do espaço de armazenamento utilizado para os dados,
mostrou-se também uma técnica para a melhoria do desempenho de consultas a esses dados, na medida em que menos
blocos são necessários para satisfazer uma solicitação de consulta. Naturalmente, existe um custo associado à
compressão e à descompressão que precisa ser levado em conta, sendo totalmente transparente para a aplicação. 
Criptogra�a TDE
Recurso para criptogra�a dos dados quando armazenados no banco de dados. É transparente para a aplicação e é aplicado
aos dados quando eles são gravados em disco, sendo descriptografados quando lidos. Trouxe mais segurança aos bancos
de dados SQL Server, inclusive mantendo a criptogra�a no backup do banco. Para restaurar um backup de um banco
criptografado, é preciso restaurar também a chave utilizada para criptografar.
PowerPivot
A versão R2 trouxe o PowerPivot, uma extensão do SSAS para fornecer acesso direto a informações analíticas (geradas no
Analysis Services) a partir do Excel, por exemplo. Tornou-se uma importante ferramenta de Business Intelligence para
usuários realizarem pivot e unpivot de tabelas diretamente em ferramentas de visualização de dados. 
 
SQL Server 2012
Foi na versão 2012 que nasceu o Always On, uma funcionalidade do SQL Server extremamente importante e conhecida.
Sucessora da versão 2008 R2, a versão 2012 teve a responsabilidade de manter o produto em constante evolução. Foi
exatamente essa a inovação principal que garantiu a continuidade.
Always On
Sendo até hoje a principal ferramenta para con�guração de clusters failover, é responsável pela implementação de Alta
Disponibilidade do SQL Server, podendo ser utilizada em cenários de Recuperação de Desastres. Vamos abordar o Always On
na aula de Alta Disponibilidade.
A versão também trouxe uma série de novidades para desenvolvedores. Novas funções para manipulação de objetos e uso em
procedimentos foram disponibilizadas, incluindo IIF, CONCAT, FORMAT, OFFSET para paginação de resultados, entre outras.
Além dessas novas funções, tivemos:
Clique nos botões para ver as informações.
As colunas IDENTITY são utilizadas para a criação de chaves primárias surrogadas, sendo baseadas em uma sequência
numérica. A versão 2012 trouxe o objeto do tipo Sequence, que cria uma sequência como esta, de forma que se pode criar
uma chave primária baseada nessa sequência.
Sequências 
Este novo tipo de índice possibilita enormes ganhos de desempenho para a carga de trabalho submetida ao banco de
dados, principalmente se estivermos trabalhando com Data Warehouse. Nesses cenários, é comum ter que recuperar os
valores distintos de uma determinada coluna. Índices column-store permitem que essa recuperação seja muito rápida,
pois não é necessário ler as linhas da maneira tradicional (SELECT DISTINCT).
Índices column-store 
 Até as versões anteriores, erros em blocos TRY-CATCH eram tratados com a cláusula RAISERROR. A versão 2012
inaugurou o uso de cláusulas THROW para disparo de exceções, em substituição às cláusulas RAISERROR.
Tratamento de erros 
 Baseada nos índices full-text, a busca semântica permite aos desenvolvedores realizarem buscas de palavras em
documentos que retornem as palavras com base no seu signi�cado, de forma similar à busca realizada por outros
mecanismos como Google.
Busca semântica 
 Fundamental na atualidade, pela primeira vez a Microsoft incluiu serviços de qualidade de dados no SQL Server. Com eles,
os desenvolvedores puderam criar regras de veri�cação de qualidade e submetê-las ao Database Engine para que fossem
checadas durantes as atualizações nos dados, incluindo padronização e enriquecimento.
Data Quality 
SQL Server 2014
A versão 2014 é marcante porque anunciou a chegada do Azure, a plataforma de nuvem da Microsoft, e toda uma nova
geração de ferramentas para migração de bancos de dados para a nuvem. Além disso, endereçou uma série de melhorias no
Always On e apresentou um novo mecanismo para bancos de dados In-Memory.
01
Always On
As evoluções apresentadas nessa versão tornaram o Always On ainda mais robusto para uma série de cenários não
previstos anteriormente. A capacidade de organização de grupos de disponibilidade trouxe mais �exibilidade e
autonomia aos administradores para implementação de suas soluções de Alta Disponibilidade e Recuperação de
Desastres.
02
In-memory
Evolução do suporte a transações in-memory, permitindo que tabelas inteiras passassem a ser alocadas na memória e
aumentando enormemente o desempenho das consultas submetidas ao banco de dados.
03
Melhorias no otimizador
Os algoritmos que estimam a cardinalidade de tabelas auxiliares foram reconstruídos nessa versão. Um dos passos
mais importantes na geração do plano de execução de uma consulta, esta é uma melhoria signi�cativa do otimizador
do SQL Server que passou a contar com estimativas bem mais próximas da realidade, o que faz com que o plano
gerado esteja mais próximo do melhor desempenho possível.
04
Clones de bancos de dados
Funcionalidade para a geração de um novo banco de dados a partir de outro banco já existente, copiando os
esquemas e os metadados deste, mas não copiando seus dados.
 Outras versões do SQL Server
 Clique no botão acima.
Outras versões do SQL Server
SQL Server 2016
 Na versão 2016 foi apresentada uma grande inovação que será muito utilizada no seu dia a dia como administrador
do SQL Server, a Query Store. Outra grande novidade da versão, o Polybase, traz um conector para Hadoop, uma
plataforma para construção de Data Lakes. Outras novidades incluem o mascaramento dinâmico de dados, melhorias
na criptogra�a e maior integração com a plataforma Azure.
SQL Server no Linux
Uma novidade que agitou o mercado de banco de dados, pelo fato de a Microsoft ter portado o SQL Server para o
Linux, o grande rival do Windows. Essa foi a primeira versão com suporte ao Linux, ainda com algumas
limitações, como processamento de queries distribuídas e replicação de bancos de dados.
Query Store
Essa ferramenta trouxe grandes avanços tanto para a monitoração do SQL Server quanto para a análise dos
planos de execução e do desempenho das cargas de trabalho.
É exatamente a Query Store que vai possibilitar um dos grandes avanços em toda a história do SQL Server, o
tuning automático, que começaria a ser oferecido na versão 2017 no Azure.
Polybase
Com o Polybase é possível conectar o SQL Server diretamente ao Hadoop, permitindo que a ingestão das bases
de dados para o sistema de arquivos dessa plataforma (HDFS) seja realizada de forma nativa, assim como a
consulta aos dados ali armazenados.
Linguagem R
O R Services da versão 2016 trouxe suporte à integração do código SQL com a linguagem R, bastante difundida
pelo foco em operações da estatística, o que vai ao encontro das necessidades atuais de Data Science.
Mascaramento dinâmico de dados
Permite quesejam criadas regras de mascaramento para dados em repouso ou em trânsito, aumentando a
segurança dos bancos de dados. Esta é uma funcionalidade especialmente importante no contexto da LGPD (Lei
Geral de Proteção a Dados).
Criptogra�a
A versão 2016 trouxe a con�guração Always Encrypted para um banco de dados, de forma que todas as
operações neste sejam criptografadas.
Always On
Uma série de melhorias no Always On foram implementadas nessa versão, aumentando o limite de réplicas
síncronas em grupos de disponibilidade, o que torna as soluções para Disaster Recovery ainda mais completas.
SQL Server 2017
Esta versão consolidou o suporte ao Linux e estreou o conceito de tuning automático, pelo qual emite recomendações
para ajustes de desempenho. Também apresentou o Machine Learning Services, um conjunto de serviços de apoio a
algoritmos de aprendizado de máquina.
Tuning automático
Baseado na Query Store, o SQL Server emite recomendações de tuning, como criação de índices e visões
indexadas. No mesmo contexto, implementou diversas melhorias no processamento das consultas, também
com base na captura dos planos de execução da Query Store.
Machine Learning Services
Possibilita a integração da linguagem SQL com a linguagem Python, amplamente utilizada atualmente. Aumentou
o leque de opções para cientistas de dados, que já contavam com o suporte à linguagem R. Fornece ainda um
conjunto de serviços de apoio a algoritmos especializados nas bibliotecas de Aprendizado de Máquina e
Inteligência Arti�cial.
SQL Graph Database
A versão 2017 trouxe ainda uma excelente notícia, a capacidade de criar grafos com base nos relacionamentos
entre as tabelas. É um recurso de extrema utilidade, principalmente quando se tem muitos relacionamentos entre
as tabelas e eles podem se tornar uma informação de fato.
SSAS e SSIS
A Microsoft mostra nessa versão que mantém um forte investimento em suas plataformas de Data Warehouse
(Analytics Services) e ETL (Integration Services), ao disponibilizar uma série de melhorias para elas. Suporte a
modelos tabulares e instâncias Linux são exemplos.
SQL Server 2019
 Versão mais recente do produto, a 2019 anunciou o Big Data Cluster para SQL Server, uma plataforma completa para
Data Science. Anunciou também recursos para virtualização de dados e melhorias relevantes no processamento de
consultas.
Big Data Cluster
Trata-se da abordagem da Microsoft para tornar possível a implementação de Data Lakes a partir do consumo de
dados depositados no próprio SQL Server. As abordagens tradicionais para uma implementação desse tipo,
utilizando Hadoop ou Spark, dependem de ingestões de dados para transferir dados dos bancos de dados para o
lake, o que demanda esforço computacional e tempo. Com essa nova abordagem, orquestrada por Kubernetes, o
Data Lake do Big Data Cluster em conjunto com o suporte a dados não estruturados tem o potencial de trazer
para o SQL Server todo um conjunto de necessidades atuais dos chamados Cientistas de Dados.
Virtualização de dados
Esta nova funcionalidade permite o mapeamento de bancos de dados em outros SGBDs, como Oracle, para os
bancos de dados do SQL Server. Essa é uma alternativa a ser considerada em cenários de dados espalhados em
diversas fontes, para os quais é preciso criar tarefas de ETL para movimentá-los, ou então jobs de replicação que
sempre são muito custosos para a administração do banco de dados.
Processamento de consultas
A Microsoft chama este novo conjunto de melhorias de Processamento Inteligente de Consultas, na medida em
que essa nova versão utiliza o suporte oferecido pela Query Store e, em alguns casos, pelo Machine Learning
Services para recomendar e atualizar os planos de execução das consultas visando ao melhor desempenho. É de
fato um grande avanço.
Saiba mais
Chegamos ao �m da parte da aula sobre a evolução do SQL Server ao longo de mais de 20 anos. Para conhecer os detalhes
dessa história, consulte as páginas da Microsoft sobre cada versão. Há um vasto material sobre todas essas versões,
disponível em: https://docs.microsoft.com/pt-br/previous-versions/sql/.
A versão Linux do SQL Server
A primeira versão do SQL Server a ter suporte para instalação sobre sistemas operacionais Linux foi a 2016, sendo consolidado
na versão 2017 e compatível com Red Hat, Suse e Ubuntu.
Segundo a Microsoft, o mecanismo do banco de dados é o mesmo para Windows e Linux, entretanto, a versão Linux possui
uma série de limitações, a maioria imposta pelas próprias diferenças entre os sistemas operacionais.
Um exemplo é o tipo de coluna FILESTREAM (SQL Server 2008). Como a funcionalidade depende diretamente de um
mapeamento para o sistema de arquivos do Windows (NTFS), a Microsoft deverá portar esse mapeamento para os sistemas
de arquivos do Linux, por exemplo, o EXT2 ou EXT3.
A versão Linux do SQL Server, apesar das limitações, tem um bom comportamento em ambientes heterogêneos, na medida em
que os administradores podem implantar bancos de dados oriundos de versões Windows com nenhuma ou pouca alteração,
utilizando as mesmas ferramentas com as quais estão acostumados, como o SQL Server Management Studio.
Saiba mais
Para conhecer os detalhes da versão do SQL Server no Linux, acesse SQL Server no Linux. Dosponível em:
https://docs.microsoft.com/pt-br/sql/linux/sql-server-linux-overview?view=sql-server-ver15
Para ver as limitações da versão 2019 no Linux, acesse Edições e recursos compatíveis do SQL Server 2019 no Linux:
https://docs.microsoft.com/pt-br/sql/linux/sql-server-linux-editions-and-components-2019?view=sql-server-
ver15#Unsupported
javascript:void(0);
javascript:void(0);
javascript:void(0);
Utilização de diferentes versões em um mesmo ambiente
É possível utilizar diferentes versões em um mesmo servidor, isto é, ter diferentes instalações SQL Server, de diferentes versões,
em uma mesma máquina, virtual ou não. Conforme veremos em aulas posteriores, uma versão mais recente pode não
suportar todas as características de uma versão mais antiga. Por exemplo, a versão 2012 não suporta algumas construções T-
SQL existentes na versão 2008 R2. Isto é especialmente importante quando se atualiza a versão das instalações SQL Server.
Comentário
Além disso, backups de uma versão posterior não são reconhecidos em versões anteriores. Portanto, ao trabalhar com
ambientes mistos, é preciso ter atenção a essas restrições de compatibilidade entre as versões.
Nível de compatibilidade
Cada versão do SQL Server tem um nível de compatibilidade padrão e suporta alguns níveis de compatibilidade anteriores. Veja
a tabela a seguir:
Versão Versão do Engine Nível de compatibilidade padrão Níveis de compatibilidade suportados
2019 15 150 150,140,130,120,110,100
2017 14 140 140,130,120,110,100
2016 13 130 130,120,110,100
2014 12 120 120,110,100
2012 11 110 110,100,90
2008 R2 10.5 100 100,90,80
2008 10 100 100,90,80
2005 9 90 90,80
2000 8 80 80
O que essa tabela informa?
Se há um banco de dados implantado no SQL Server 2005 e se deseja migrá-lo para uma instância 2012, pode-se restaurá-lo na
nova instância sem alterações na sintaxe dos procedimentos porque o SQL Server 2012 suporta o nível de compatibilidade 90,
que é o padrão do SQL Server 2005.
Por outro lado, para migrá-lo para uma instância 2017, deve-se, por exemplo, migrá-lo para uma instância 2012 e fazer as
correções necessárias para levantar o nível de compatibilidade para 110. Em seguida, é possível levá-lo para a instância 2017,
porque esta suporta o nível 110, padrão do 2012.
 Licenciamento
 Clique no botão acima.
Licenciamento
A Microsoft comercializa atualmente o SQL Server em dois modelos principais de licenciamento: A edição Standard e a
edição Enterprise. As principais diferenças entre essas duas versões dizem respeito aos limites de uso dos recursos
computacionais.
A edição Enterprise permite que se utilizem todos os núcleos disponíveis no servidor. Já a versão Standard permite
que se use somente 24 núcleos ou todos os núcleos de 4 soquetes, o que for menor. Não é difícilatualmente encontrar
servidores com capacidade de 96 núcleos.
Veja, por exemplo, a especi�cação de um servidor Huawei RH5885H V3 . Ele possui 4 soquetes com capacidade
para até 96 núcleos. Se estiverem preenchidos completamente, só será utilizado ¼ da capacidade com a versão
Standard! Nesse caso, para usar a capacidade total da máquina, deve-se necessariamente licenciar a versão
Enterprise.
A versão Standard é mais indicada para sistemas de menor porte, pois naturalmente possui um custo de
licenciamento menor. A edição Enterprise é mais indicada para sistemas com requisitos de disponibilidade e
processamento maiores, por exemplo, um sistema de reservas de bilhetes aéreos ou um sistema de atendimento a
clientes de um grande banco, mas também é a mais indicada quando se tem um grande número de bancos de dados
de sistemas diferentes, não necessariamente de missão crítica.
Há ainda as edições Web, Express, Express with Advanced Services, Express LocalDB e Developer. A versão Express,
assim como a Developer, não tem custo de licenciamento. Você pode realizar o download e executar a instalação em
sua própria máquina. Os limites impostos nessas versões quanto ao uso de recursos são bastante maiores. O
tamanho de um banco de dados, por exemplo, não pode ultrapassar 10 GB.
A versão Express with Advanced Services possui o Integration Services que, como visto anteriormente, é um
componente adicional do SQL Server utilizado para implementações de ETL. A versão Express LocalDB é utilizada de
forma embarcada em aplicações para dispositivos móveis. Já a versão Web, em termos de limitações, situa-se entre a
versão Express e a Standard. Ela pode utilizar até 16 cores, por exemplo, enquanto a versão Express possui o limite de
4 cores.
Para ver em detalhes todos os recursos e as limitações de cada edição, procure por sql server 2019 editions
comparison no site da Microsoft.
Licenciamento para máquinas virtuais
 As licenças para máquinas virtuais são comercializadas em pacotes (packs) de 2 cores cada um. Então, ao adquirir 12
licenças para máquinas virtuais, você pode instalar o SQL Server em todas as máquinas virtuais que compartilhem um
hardware com 24 núcleos de processamento. Isso pode ser muito vantajoso em alguns cenários, tanto do ponto de
vista de utilização de várias instalações SQL Server distintas, quanto do ponto de vista �nanceiro. Vamos ver mais
sobre isso em Instalação do SQL Server.
Licenciamento para containers
 O uso de containers Docker e sua orquestração com Kubernetes tem crescido bastante nos últimos anos e se tornou
a base para a infraestrutura de nuvens privadas e públicas, principalmente por causa da elasticidade. A capacidade de
realizar o scale-out e o scale-in faz dessas plataformas uma escolha bastante apropriada para cenários em que a
capacidade de processamento deve aumentar ou diminuir de acordo com a demanda. Vamos ver mais sobre
containers na aula de Alta Disponibilidade.
O licenciamento do SQL Server para essas plataformas prevê que sejam licenciados os núcleos virtuais de cada
container SQL Server. Há também a opção de licenciar todos os núcleos de uma máquina física. Nesse caso, você
poderá executar tantos containers SQL Server quantos forem o número de núcleos da máquina física.
javascript:void(0);
Leitura
Para conhecer em detalhes todas as características do licenciamento Microsoft para as diferentes plataformas, faça o
download do Microsoft SQL Server 2019 licensing guide, no site da Microsoft. Nesse guia você vai encontrar seções bem
de�nidas para cada plataforma.
Política de ciclo de vida
A política de ciclo de vida da Microsoft para o SQL Server compreende os períodos que delimitam o início e o término do ciclo
de vida dele. Este é sempre de�nido com base na edição e na versão do SQL Server. Então, por exemplo, você vai encontrar as
datas de início e término do ciclo de vida para SQL Server 2012 Enterprise Edition.
Normalmente o ciclo de vida de uma versão SQL Server dura 10 anos, entre o lançamento e o �m do suporte para o último
Service Pack, mas isso pode variar.
É fundamental que o administrador esteja atento a esses prazos e também à política como um todo, para que possa planejar
as atualizações de versão.
Saiba mais
Veja na Política de ciclo de vida da Microsoft  as tabelas de ciclo de vida dos produtos da empresa. Pesquisando por sql server
2012, você pode concluir que o suporte à edição SQL Server Enterprise Edition se encerra em 12 de julho de 2022.
javascript:void(0);
javascript:void(0);
Conclusão
Vimos como o SQL Server nasceu e evoluiu ao longo do tempo, tornando-se um dos líderes no segmento de SGBDs. Você,
como administrador de bancos de dados, deve lembrar-se de que o produto avançou a partir de um SGBD unicamente
relacional para uma plataforma que atende a outras necessidades, como Data Warehouse, ETL, Ciência de Dados e Inteligência
Arti�cial. Todas ou parte dessas soluções estarão no seu dia a dia.
Vimos também como o produto é comercializado, quais as limitações
impostas nas edições e quais as restrições para a atualização de
versões. Você, como administrador do SQL Server, deve estar sempre
atualizado sobre essas informações. É parte do seu trabalho olhar
para a frente e planejar a atualização da infraestrutura de dados.
Atividades
1. Qual das propriedades listadas a seguir não é implementada pelo Microsoft SQL Server?
a) Controle de transações
b) Gerenciamento de concorrência
c) Segurança no acesso aos dados
d) Elasticidade
e) Replicação de dados
2. Relacione as colunas a seguir:
SQL Server 2000 1 SQL Server 2005 2 SQL Server 2008 3 SQL Server 2012 4 SQL Server 2014 5
SQL Server 2017 6 SQL Server 2019 7
a) XQuery
b) Big Data Cluster
c) Visões materializadas
d) In-Memory OLTP
e) Recomendações de tuning
f) Filestream
g) Always On
3. Leia a seguinte a�rmativa: “O SQL Server é um SGBD que oferece um mecanismo robusto de banco de dados que
implementa um dialeto SQL estendido a partir do padrão ANSI que pode ser integrado com as linguagens R e Python, entre
outras, em um ambiente de Big Data com acesso a algoritmos de Aprendizado de Máquina e Inteligência Arti�cial”. Marque, a
seguir, a resposta correta:
a) A afirmativa está correta.
b) A afirmativa está incorreta.
4. Quais das ações a seguir devem ser tomadas para que se migre um banco de dados hospedado em uma instância 2012,
com nível de compatibilidade 90, para uma instância instalada com a versão 2019?
1. Migrar o banco sem alterações. 
2. Elevar o modo de compatibilidade do banco de dados para 110, fazendo as alterações necessárias, e migrar o banco para o
SQL 2017, sem alterações. 
3. Migrar o banco de dados para o SQL 2014, sem alterações; em seguida, migrar o banco de dados para o SQL 2017, fazendo
as alterações necessárias. 
4. Migrar o banco de dados para o SQL 2014, fazendo as alterações necessárias; em seguida, migrar o banco de dados para o
SQL 2017, fazendo as alterações necessárias. 
5. Migrar o banco de dados para o SQL 2014, fazendo as alterações necessárias; em seguida, migrar o banco de dados para o
SQL 2017, sem alterações.
Assinale a opção correta:
a) 1,2 e 3
b) 1,2 e 4
c) 2, 3 e 5
d) 2, 4 e 5
e) 3, 4 e 5
5. Qual edição do SQL Server maximiza o uso do hardware disponível?
a) SQL Server Web Edition
b) SQL Server Developer Edition
c) SQL Server Standard Edition
d) SQL Server Enterprise Edition
e) SQL Server Full Edition
Notas
Instância
Cada uma das diferentes instalações SQL Server executadas na mesma máquina.
Como o próprio nome diz, essas tabelas são alocadas diretamente em memória, sendo esta a principal diferença para as
tabelas temporárias que garantiu melhorias de desempenho para as consultas que utilizam tal recurso.
Um gatilho desse tipo substitui completamente a execução do comando original e pode ser utilizado em todos os cenários para
os quais é necessário algum tipo de crítica e/ou atualização de dados em mais de uma tabela.
Em vez da visão tradicional, na qual somente a de�nição é armazenada, na visãomaterializada os dados são persistidos, da
mesma forma que em uma tabela. Em muitos cenários, conforme veremos na aula de Tuning, a visão materializada pode
aumentar o desempenho de consultas ao banco de dados.
Referências
DB-ENGINES. DB-Engines ranking. 2020. Disponível em: https://db-engines.com/en/ranking. Acesso em: 21 maio 2020.
 
HUAWEI. RH5885H V3. 2020. Disponível em: https://support-it.huawei.com/server-3d/res/server/rh5885hv3/index.html?
lang=en. Acesso em: 21 maio 2020.
  MICROSOFT. Documentação de versões anteriores do SQL Server. 2020a. Disponível em: https://docs.microsoft.com/pt-
br/previous-versions/sql/. Acesso em: 21 maio 2020.  
MICROSOFT. Edições e recursos compatíveis do SQL Server 2019 no Linux. 2020b. Disponível em:
https://docs.microsoft.com/pt-br/sql/linux/sql-server-linux-editions-and-components-2019?view=sql-server-
ver15#Unsupported. Acesso em: 21 maio 2020.
 
MICROSOFT. Editions and supported features of SQL Server 2019 (15.x). 2020c. Disponível em:
https://docs.microsoft.com/en-us/sql/sql-server/editions-and-components-of-sql-server-version-15?view=sql-server-ver15.
Acesso em: 21 maio 2020.
 
MICROSOFT. Política de ciclo de vida da Microsoft. 2020d. Disponível em: https://docs.microsoft.com/pt-br/lifecycle/. Acesso
em: 21 maio 2020.
 
MICROSOFT. SQL Server no Linux. 2020e. Disponível em: https://docs.microsoft.com/pt-br/sql/linux/sql-server-linux-overview?
view=sql-server-ver15. Acesso em: 21 maio 2020.
 
MICROSOFT. WITH common_table_expression (Transact-SQL). 2020f. Disponível em: https://docs.microsoft.com/pt-br/sql/t-
sql/queries/with-common-table-expression-transact-sql?view=sql-server-ver15. Acesso em: 21 maio 2020.
 
MICROSOFT. Microsoft SQL Server 2019 licensing guide. 2019. Disponível em:
https://download.microsoft.com/download/6/6/0/66078040-86d8-4f6e-b0c5-
e9919bbcb537/SQL%20Server%202019%20Licensing%20guide.pdf. Acesso em: 21 maio 2020.
Próxima aula
Diagramas de arquitetura do SQL Server;
Integração dos principais componentes da arquitetura do SQL Server;
javascript:void(0);
javascript:void(0);
javascript:void(0);
javascript:void(0);
javascript:void(0);
javascript:void(0);
javascript:void(0);
javascript:void(0);
javascript:void(0);
Garantia das propriedades ACID no SQL Server.
Explore mais
Leia o texto:WITH common_table_expression (Transact-SQL)
As CTE (Common Table Expressions) nasceram no SQL Server 2005 e são muito utilizadas até hoje, constituindo-se uma
excelente ferramenta para administradores e desenvolvedores. Estude a descrição completa, procure um exemplo de CTE
no documento e pense como resolveria o mesmo problema sem utilizar CTE.
javascript:void(0);
/
Administração de Banco de Dados II 
Aula 2: Arquitetura do SQL Server
Apresentação
Esta segunda aula da disciplina Administração de Bancos de Dados II é uma apresentação da arquitetura do Microsoft
SQL Server.
Conheceremos os componentes principais desse sistema gerenciador de bancos de dados, permitindo a compreensão da
integração entre eles.
Durante a aula, apresentaremos um diagrama de arquitetura que mostra como os componentes trabalham juntos para a
atender às solicitações enviadas pelos clientes. Trata-se de conceitos fundamentais para o administrador do SQL Server
Objetivos
Identi�car os principais componentes do Microsoft SQL Server;
Descrever as características dos principais componentes da arquitetura do SQL Server;
Discutir como os componentes se integram para executar as tarefas do SGBD e atender às solicitações de clientes.
Conhecendo a arquitetura de um SGBD
A arquitetura de uma solução é o ponto de partida para que se entenda o
que e como ela atinge os objetivos. No caso de um Sistema Gerenciador de
Bancos de Dados (SGBD), como o SQL Server, compreender a arquitetura é
identi�car os principais componentes e como eles se integram para, por
exemplo, resolver as consultas submetidas ao banco de dados.
/
Como há diversos aspectos a serem considerados na arquitetura de um SGBD, é comum enxergar a solução como um
conjunto de subsistemas que atendem a objetivos especí�cos. Um subsistema bastante importante, por exemplo, é o
gerenciador de processamento de consultas. Ele é o responsável por analisar uma consulta, gerar um plano de execução para
ela e executá-la. O otimizador do banco de dados é um dos componentes desse subsistema, de fato um dos mais importantes
de todo o SGBD.
Daqui em diante pensaremos a arquitetura do SQL Server como um conjunto de subsistemas, integrados entre si, com cada um
deles contendo diversos componentes, também integrados entre si. Todos eles trabalham juntos e cooperam de forma
coordenada para entregar os resultados esperados pelos administradores, desenvolvedores e usuários.
Arquitetura geral
Um bom ponto de partida é a próxima imagem. Ela ilustra a chegada de uma requisição de um cliente e como esta atravessa
os principais componentes até a entrega do resultado.
Com base neste diagrama, podemos destacar os seguintes subsistemas:
1
Protocol Layer;
2
Relational Engine;
3
Storage Engine;
4
Buffer Pool.
/
 Fonte: (MICROSOFT, 2017, on-line)
Vamos examinar os subsistemas dessa arquitetura para entender a responsabilidade deles e conhecer os principais
componentes de cada um. Para ver outros diagramas de arquitetura do SQL Server, pesquise por “sql server database engine
architecture diagram”. Você poderá encontrar também diagramas dos subsistemas listados.
Protocol Layer
 A camada de Protocolos é a porta de entrada do SQL Server. É por meio dela que os clientes se conectam ao SGBD e enviam
as solicitações. A conexão do cliente com o SQL Server é estabelecida sobre um protocolo de comunicação, sendo que
atualmente são suportados três protocolos, a saber: TCP/IP, Named Pipes e Shared Memory. O suporte a esses protocolos é
oferecido pelo SNI (Service Network Interface).
TCP/IP
Protocolo mais frequentemente
utilizado por aplicações que
acessam o banco de dados. Uma
conexão típica de um cliente com
o servidor SQL Server utiliza o
endereço IP (Internet Protocol) do
servidor e a porta TCP
(Transmission Control Protocol)
pela qual o serviço
correspondente está escutando.
A porta default para uma
instalação SQL Server é a 1433,
mas é possível alterá-la durante a
instalação ou posteriormente
pelo Con�guration Manager.
Named Pipes
Protocolo que utiliza o
subsistema de intercomunicação
entre processos do Windows.
Para que um cliente se conecte a
um servidor utilizando esse
protocolo, é preciso que os dois
estejam na mesma subrede.
Utiliza a porta TCP 445 por
default.
Shared Memory
Memória compartilhada no
próprio servidor, logo, tanto o
cliente quanto o servidor devem
estar instalados na mesma
máquina para que esse protocolo
seja utilizado. Um caso típico de
uso de Shared Memory é o
próprio SQL Server Management
Studio (SSMS), quando se acessa
bancos de dados locais para
realizar tarefas administrativas.
/
Note, no diagrama apresentado, o uso do protocolo TDS (Tabular Data Stream) para transferência de dados entre o cliente e o
servidor SQL Server. O TDS é utilizado desde a parceria da Microsoft com a Sybase e é o protocolo responsável por carregar
tanto as solicitações enviadas a partir dos clientes quanto enviar a eles as respostas do SQL Server.
Quando um usuário se conecta a uma instância e envia um comando SELECT, esse comando é encapsulado em uma
mensagem TDS e a mensagem é carregada por meio de um dos protocolos suportados, TCP/IP por exemplo, até o endpoint
TDS que se situa nessa camada, Protocol Layer. O SELECT é resolvido pelo engine do SQL Server e devolvido para a mesma
camada que, por sua vez, encapsula a resposta em uma nova mensagem TDS e a envia pelo mesmo endpoint, TCP/IP nesse
caso, para o cliente. Todas as mensagens entre cliente e servidor seguirão esse �uxo.
Aqui residem as primeiras mensagens de erro que você, como administrador, vai tratar. São as mensagens de erro de conexão
ao SQL Server. Sempre que uma mensagem TDS não conseguir encontrar seu endpoint correspondente, uma mensagemde
erro será devolvida ao cliente, nesse caso, não pelo SNI, mas pelo próprio protocolo de comunicação que, não conseguindo
fechar a conexão, devolve uma mensagem de erro para o cliente que a solicitou. Trataremos desses erros na aula de Instalação
e Con�guração do SQL Server.
Saiba mais
Para ver detalhes da camada de protocolos do SQL Server, visite SQL Server Protocols , da Microsoft, disponível em:
https://docs.microsoft.com/en-us/openspecs/sql_server_protocols/ms-sqlprotlp/f16558b2-4561-45be-89c9-6f9114514c97.
Relational Engine
Uma vez que a conexão foi estabelecida na camada de serviço de rede, por meio de um dos protocolos disponíveis, o cliente já
pode enviar solicitações. Estas virão na forma de uma mensagem TDS que, ao ser extraída do pacote, tem o conteúdo
veri�cado.
Tratando-se de uma solicitação expressa na linguagem SQL, ela é transferida ao Relational Engine, que possui as seguintes
funções:
javascript:void(0);
/
1
Veri�car a sintaxe do comando contido na
solicitação;
2
Gerar um plano de execução para o
comando;
3
Executar o comando.
As três funções são de responsabilidade de três componentes distintos: Command Parser, Optimizer e Query Executor.
 Componentes
 Clique no botão acima.
/
Command Parser
É o componente responsável pela veri�cação da sintaxe T-SQL do comando a ser executado. Caso haja um erro nessa
sintaxe, uma resposta contendo uma mensagem de erro é enviada ao cliente. Caso contrário, será de�nido um plano
de execução para o comando.
Mas, como o parser veri�ca se a sintaxe de uma consulta está correta?
Sabemos que uma linguagem é composta de instruções, parâmetros, palavras reservadas e regras a serem seguidas
por essas construções. O que o parser faz é identi�car os objetos da linguagem, con�rmando que eles são conhecidos,
e colocá-los em uma ordem, na forma de uma árvore, veri�cando que o tipo de árvore é conhecido. Se um objeto não é
conhecido, temos um erro de sintaxe. Se a árvore construída está faltando um pedaço, temos outro tipo de erro de
sintaxe.
Veja alguns exemplos de solicitações que retornam erro na fase de parsing:
SELECT * Tabela
A instrução SELECT está correta, * é conhecido e TABELA eventualmente existe. Na montagem da árvore, veri�ca-se
que um elemento esperado não foi de�nido, nesse caso, a palavra reservada FROM.
SELECT * FROM Tabela WHERE Coluna1=@variavel
Nesse caso todos os objetos são esperados, de forma que a árvore está correta. Entretanto, um dos elementos,
@variavel, não está declarado, infringindo uma regra da linguagem.
É possível forçar a utilização do Command Parser sem executar a instrução SQL propriamente dita. Para isso, ative a
opção PARSEONLY e execute os comandos desejados.
SET PARSEONLY ON 
DECLARE @variavel INT 
SET @variavel=1 
SELECT * FROM Tabela WHERE Coluna1=@variavel 
GO 
SET PARSEONLY OFF
Nesse exemplo, o comando SELECT não será executado porque ativamos a opção PARSEONLY, que faz somente o
Command Parser ser executado. Como não há erros de sintaxe, a mensagem de retorno con�rma que o comando
executa com sucesso.
Um subproduto desse componente é, como vimos, uma árvore. Ela é chamada Parse Tree e pode ser vista no exemplo
a seguir. Considere a seguinte consulta e a árvore gerada pelo Command Parser:
SELECT FirstName, LastName FROM Students WHERE City=’Playa Del Rey’ AND Age>=30
/
Note como os elementos da solicitação são organizados e como as cláusulas são compostas. O operador AND recebe
duas condições. Na árvore essas condições estão representadas como nós �lhos do nó AND. Da mesma forma, as
colunas que fazem parte da lista do SELECT estão abaixo do nó SELECT LIST.
Essa árvore será utilizada na passagem do controle para o otimizador que vai gerar um plano de execução para a
consulta. Antes, porém, cabe uma informação importante. Como veremos na próxima seção, o otimizador é
responsável por gerar os planos de execução para as consultas que são submetidas ao banco de dados. Todos esses
planos de execução gerados são armazenados em uma área para reutilização, caso a mesma consulta seja
reexecutada.
A área se chama Plan Cache e nós a estudaremos detalhadamente na seção de Gerenciamento de Memória. Por ora, é
importante sabermos que, nessa passagem de controle, o engine checa se já existe um plano gerado para a consulta.
Se houver, ele é recuperado e passado para o outro componente do Relational Engine, o Query Executor.
Optimizer
O otimizador é o componente que recebe uma árvore de consulta e gera um plano de execução, que corresponde a um
passo a passo para a execução da consulta.
Mas por que é necessário um otimizador para gerar um passo a passo?
Porque existem muitas maneiras de executar uma consulta. Por exemplo, para executar a consulta anterior, podemos
percorrer a tabela Students inteira e selecionar todas as linhas que satisfaçam às duas condições impostas. Ou, se
existir um índice para a coluna City, você pode percorrer esse índice selecionando todas as linhas que satisfaçam à
condição City=”Playa Del Rey” e, em seguida, acessar diretamente as linhas correspondentes em Students,
selecionando somente aquelas que satisfaçam à Age>=30. Ou, ainda, se existir um índice para a coluna Age, podemos
percorrê-lo selecionando todas as linhas que satisfaçam à condição Age>=30 e, em seguida, acessar diretamente as
linhas correspondentes em Students, selecionando somente aquelas que satisfaçam à City=”Playa Del Rey”. E se os
dois índices existirem? E se existir um índice composto? Qual dessas opções é a melhor?
Existem potencialmente centenas ou milhares de maneiras de executar uma consulta mais complexa. Por isso, o
otimizador é absolutamente necessário e, mais do que isso, é um dos componentes mais sensíveis de um Sistema
Gerenciador de Bancos de Dados.
O otimizador é composto por algoritmos so�sticados que tem a responsabilidade de gerar o melhor plano de execução
para uma consulta, dadas as restrições associadas ao tempo de geração e aos recursos disponíveis para o Relational
Engine e para o Storage Engine.
 Fonte: (SRIVASTAVA, 2015, on-line).
/
Que restrições são essas?
O otimizador não tem todo o tempo do mundo para escolher o melhor plano de execução. Tampouco possui recursos
de CPU e memória in�nitos. Também não tem ao seu dispor todos os índices de todas as tabelas referenciadas pela
consulta.
 É importante entender que as restrições levam o otimizador a escolher um plano de execução que pode não ser
exatamente o melhor para a consulta. Aí está a complexidade dos algoritmos que o compõem. Caso não houvesse
restrição alguma, o otimizador poderia avaliar todos os planos de execução possíveis e chegaria certamente ao
melhor, mas o tempo necessário para a operação, na maioria dos casos, tornaria a execução da consulta inviável.
Para realizar uma escolha, primeiramente ele seleciona as opções que serão avaliadas. Depois ele calcula o custo
associado à opção avaliada. A escolha do otimizador é baseada no custo do plano de execução, ou seja, depois que
ele calcula os custos associados aos planos avaliados, seleciona o que tem o menor custo.
Discutiremos esses custos em detalhes na aula de Tuning. Por ora, é importante saber que esse componente vai gerar
um plano de execução, que consideraremos o melhor (para as restrições existentes no momento da geração), e vai
entregar esse plano ao Query Executor.
Query Executor
Este é o componente responsável pela execução da consulta, com base no plano de execução entregue pelo
otimizador. Ele executa o passo a passo do plano, na ordem de�nida pelo plano, e interage com o Storage Engine
sempre que houver necessidade de acesso aos dados do banco de dados, para leitura ou para escrita.
Veja uma imagem do pipeline completo de execução de uma consulta.
 Fonte: (MICROSOFT, 2019e, on-line).
Saiba mais
Para ver detalhes sobre o Relational Engine do SQL Server, visite o Guia da arquitetura de processamento de consultas, da
Microsoft, disponível em:  https://docs.microsoft.com/pt-br/sql/relational-databases/query-processing-architecture-guide?view=sql-server-ver15.
javascript:void(0);
/
/
Storage Engine
Quando o plano de execução precisa recuperar ou atualizar dados, entra em cena o subsistema Storage Engine. Nele há dois
caminhos bem de�nidos: O da leitura e o da escrita. Em ambos os casos, o Query Executor faz uma solicitação ao Access
Methods para tratar a recuperação ou a atualização de dados.
Access Methods
Este componente do Storage Engine é responsável por manter um repositório de métodos de acesso, incluindo o código
necessário para recuperar dados assim como as estruturas de dados propriamente ditas. Dessa forma, quando o Query
Executor solicita ao Access Methods a leitura de uma tabela, esse componente recupera o método de acesso correspondente e
a estrutura de dados necessária para armazenar os dados que serão recuperados pelo seu código.
Da mesma forma, se o Query Executor solicita ao Access Methods uma atualização de linhas de uma determinada tabela, esse
componente seleciona o código a ser executado para a atualização e as estruturas de dados a serem utilizadas por esse
código de atualização, de forma a recebê-los do próprio Query Executor.
E quem executa o código?
É aqui que leitura e escrita seguem caminhos diferentes. Veja na imagem da arquitetura geral do SQL Server os dois
componentes ao lado do Access Methods. Se a operação for uma leitura, vamos seguir o caminho do BUFFER MANAGER. Se a
operação for uma escrita, vamos seguir primeiro o caminho do BUFFER MANAGER, depois do TRANSACTION MANAGER e, por
último, do BUFFER MANAGER novamente.
Buffer Manager
O Access Methods solicita ao Buffer Manager que recupere os dados para que ele possa encaminhá-los de volta ao Query
Executor.
Para isso, o Buffer Manager veri�ca se os dados estão no Buffer Pool, em uma área especial chamada Data Cache
(representada pelo quadrado D na imagem). Caso estejam, recupera-os a partir dessa área e os encaminha de volta ao Access
Methods. Caso contrário, o Buffer Manager executa uma solicitação de I/O (Input/Output) para recuperar os blocos de disco
nos quais estão armazenados os dados. Quando recuperados, são armazenados no Data Cache do Buffer Pool e
encaminhados de volta ao Access Methods.
Nos casos de solicitação de escrita, antes que o controle seja transferido ao Transaction Manager, o Buffer Manager também é
acionado para garantir que os dados atuais estejam no Data Cache.
Páginas
Aqui cabe uma informação importante. Fisicamente, os dados são armazenados em páginas dentro dos arquivos de
dados (*.mdf e *.ndf) correspondentes aos bancos de dados. Quando há uma solicitação de leitura ou escrita de dados, são as
páginas que são lidas ou atualizadas. No Buffer Pool, também, temos páginas de dados armazenadas no Data Cache.
O tamanho de uma página é igual a 8.192 bytes, sendo que todas elas possuem um cabeçalho de 96 bytes. Este cabeçalho
inclui o número da página e o tipo da página. Existem vários tipos de página além das páginas de dados, por exemplo, páginas
de índices e páginas que contêm informações sobre as próprias páginas. Veja a seguir um esquema de organização de uma
página de dados:
https://estacio.webaula.com.br/cursos/go0410/aula2.html
/
Fonte: (MICROSOFT, 2019b, on-line).
Na imagem apresentada, podemos observar o cabeçalho da
página, as linhas de dados e o espaço livre na página.
Naturalmente, novas linhas de dados vão sendo inseridas e
as já existentes vão sendo atualizadas. O Storage Engine
monitora o uso das páginas e dispara um Page Split para
dividir o conteúdo de uma página em duas, de forma a
garantir que as páginas não cheguem a 100% de ocupação.
Há também a limitação dos arquivos de dados e dos
próprios discos nos quais estão armazenados os arquivos,
mas isso é um assunto que veremos na aula de
Administração de Bancos de Dados.
Transaction Manager
É o componente do Storage Engine responsável pelo gerenciamento das transações, incluindo o tratamento das solicitações de
escrita no banco de dados. Você se lembra das propriedades ACID? É aqui que elas são garantidas pelo SQL Server.
 Note, na imagem referente à arquitetura do SQL Server, que o TRANSACTION MANAGER interage com dois subcomponentes:
TRANSACTION LOG e DATA FILES.
Quando uma solicitação de escrita é encaminhada pelo ACCESS METHODS,
o TRANSACTION MANAGER grava as atualizações primeiro no
TRANSACTION LOG.
Por quê? 
Para garantir a Durabilidade. A solicitação que vem do Access Methods requisita que as atualizações sejam gravadas no
arquivo de log de transações. No caso de uma falha do servidor, todas as transações podem ser recuperadas a partir desse
arquivo.
Quando a con�rmação é recebida, o controle volta para o Buffer Manager para que ele execute a alteração nas páginas de
dados que estão no Data Cache. Em seguida, o Access Methods informa ao Query Executor que a atualização foi executada e
retorna a ele o resultado.
Todos os registros gravados no Transaction Log recebem um identi�cador sequencial chamado Log Sequence Number (LSN).
Note que, até agora, os Data Files ainda não foram atualizados. Essa é a estratégia do SQL Server para a execução de
atualizações com bom desempenho, sem prejuízo para a garantia das propriedades ACID. As páginas de dados que são
atualizadas no Buffer Pool e �cam diferentes das páginas correspondentes em disco são chamadas Dirty Pages.
De tempos em tempos, um processo chamado Lazy Writer veri�ca o Buffer Pool, especi�camente o quanto de espaço livre
existe no Data Cache. É importante para o engine que haja sempre algum percentual do espaço do Data Cache livre para
acomodar novas solicitações. Então, caso o percentual esteja muito baixo, o Lazy Writer dispara o processo de escrita das Dirty
Pages em disco e remove as páginas atualizadas do Buffer Pool. Assim obtém mais espaço livre no Data Cache.
/
Existe também um outro processo, denominado Checkpoint, que é
ativado entre intervalos de tempo não regulares para garantir que
todas as transações con�rmadas, isto é, aquelas nas quais o COMMIT
foi executado, tenham suas alterações persistidas em disco. Nesse
processo, as Dirty Pages não são removidas do Buffer Pool; ao
contrário, são marcadas como Clean Pages.
E qual o tempo entre um checkpoint e outro?
 Toda vez que um Checkpoint é executado, uma entrada no Log File é inserida informando que naquele ponto foi realizado um
checkpoint. Conforme foi dito, os intervalos de tempo não são regulares. Isso ocorre porque o processo Checkpoint monitora o
Log File e executa o checkpoint somente quando o número de registros (após o último checkpoint) é igual ao número estimado
de operações que podem ser processadas no intervalo de tempo de�nido pela con�guração Recovery Interval do banco de
dados. Portanto, esse tempo pode variar entre um checkpoint e outro, pois depende diretamente da atividade no database.
Os checkpoints são também disparados por outros eventos que ocorrem no SGBD. Por exemplo, quando fazemos uma cópia
(backup) do banco de dados, um checkpoint é criado para descarregar as Dirty Pages da memória para o disco e gerar um
identi�cador no Transaction Log.
Locks
Um aspecto extremamente importante no gerenciamento das transações é o controle dos Locks (Bloqueios). Locks são
disparados pelo engine do SQL Server para garantir o isolamento das transações, isto é, a capacidade de executar transações
simultâneas sobre o mesmo banco de dados sem que qualquer uma inter�ra na execução de qualquer outra.
Comentário
Quando falamos em interferência de uma transação em outra, devemos pensar no conjunto de dados que as transações
processam, mais especi�camente no estado desses dados.
Cada transação reconhece os estados inicial e �nal dos dados de todas as outras transações, mas elas não têm acesso aos
estados intermediários gerados por essas transações concorrentes. É por isso que chamamos essa característica intrínseca do
gerenciamento das transações de Isolamento.
Quando uma transação é executada, o Storage Engine determina quais bloqueios são necessários, incluindo a granularidade de
cada um que podeser no nível da tabela, da página de dados ou da linha da tabela. Quando a transação é �nalizada, os
bloqueios são liberados.
Existem diversos tipos de bloqueios que dependem do tipo de operação que a transação executa. Caso ela execute um
UPDATE em uma tabela, o bloqueio é do tipo exclusivo e as outras transações devem aguardar a liberação dele para que
possam fazer as próprias atualizações. É dessa forma que o isolamento entre as transações é garantido. Vamos ver mais
detalhes sobre locks na aula Monitoração e Gerenciamento de Processos no SQL Server. Por ora, devemos saber que esse
controle é executado pelo TRANSACTION MANAGER e garante o isolamento entre as transações.
/
Saiba mais
Para ver detalhes do Storage Engine do SQL Server acesse o Guia de arquitetura e gerenciamento do log de transações do SQL
Server.
Sobre Checkpoints, acesse os Pontos de veri�cação de banco de dados (SQL Server).
Sobre Bloqueios, acesse o Guia de controle de versão de linha e bloqueio de transações, todos da Microsoft:
Buffer Pool
O Buffer Pool é composto pelos endereços de memória disponíveis para o SQL Server. Na seção anterior nós vimos como
essas áreas são utilizadas e como é importante maximizar o número de solicitações satisfeitas por dados no Data Cache (para
minimizar o número de solicitações de I/O) e manter um percentual desses endereços vazios, de forma que novas solicitações
possam ser atendidas pelo Buffer Manager.
O Buffer Pool é totalmente necessário?
Se esse componente não existisse, todas as solicitações de acesso a dados deveriam ser satisfeitas por requisições de I/O. Em
sistemas com grandes cargas de trabalho, nós poderíamos en�leirar muitas requisições levando o tempo de resposta às
solicitações a tornar o uso do sistema inviável.
Naturalmente o SQL Server não pode alocar toda a memória disponível para os processos. Assim, o desa�o imposto ao
gerenciamento de memória do SGBD é garantir que o Buffer Pool tenha endereços de memória su�cientes para acomodar a
carga de trabalho submetida a ele, enquanto mantém o SO (Sistema Operacional) capaz de acomodar os próprios processos.
Esse é um equilíbrio muito importante também no nível do SO porque quando há pouca memória para seus processos,
aumenta a quantidade de paginação entre memória e disco (swap) e isso pode degradar o desempenho do sistema como um
todo, impactando o próprio SQL Server.
Dizemos que o gerenciamento de memória é dinâmico porque o SQL Server monitora tanto o seu Buffer Pool quanto a
memória disponível na máquina, alocando e liberando endereços de memória conforme a necessidade.
No Buffer Pool há duas áreas principais, o Data Cache e o Plan Cache. Como visto anteriormente, no Data Cache residem as
páginas de todos os dados de consulta e atualizações. No Plan Cache estão todos os planos de execução das consultas e
atualizações. Tanto as páginas de dados quanto os planos de execução são encaminhados ao Buffer Pool pelo Storage Engine.
Uma nota importante sobre essas operações no Buffer Pool: É aqui que
começam a acontecer as esperas. Existem muitos tipos de esperas, os
chamados wait types, que ocorrem quando uma operação precisa esperar
pela execução de uma tarefa. Um exemplo bastante comum de espera é o
PAGEIOLATCH que se refere a uma operação de transferência de dados do
disco para o Data Cache. Enquanto as páginas de dados não são lidas, a
tarefa de leitura dos dados �ca no estado de espera. Vamos ver mais
detalhes sobre wait types e como eles impactam as operações no SQL
Server na aula de Monitoração e Gerenciamento de Processos.
javascript:void(0);
javascript:void(0);
javascript:void(0);
/
A versão 2014 trouxe uma novidade na arquitetura do SQL Server. O Buffer Pool passou a contar com um segundo nível para cache
de dados implementado em discos SSD (Solid State Drive), chamado de L2 Buffer Pool Backing Store.
Os SSDs são conhecidos principalmente pela capacidade de realizar um número bem maior de IOPS (Input/Output Operations Per
Second) que os HDDs (Hard Disk Drives). Especialmente para operações aleatórias pequenas, este número é tão maior quanto
menor for o tamanho do bloco a ser lido e/ou escrito.
Como vimos anteriormente, o tamanho de uma página de dados no SQL Server é 8 KBytes. Se você observar o grá�co de
comparação de IOPS no link acima, pode concluir que o número de operações de leitura e escrita por segundo no SSD pode ser
aproximadamente 100 vezes maior do que no HDD. Assim, faz sentido alocar espaço em um disco SDD para servir como L2 (level
2) no cache de dados, deixando o Buffer Pool em memória como L1.
Em uma arquitetura de gerenciamento de memória com dois níveis de cache de dados, o L2 em SSD funciona como uma extensão
do L1 em memória, sendo que L1 armazena as Clean Pages e as Dirty Pages, e L2 armazena somente Clean Pages. Por que essa
diferenciação? Para que os processos Lazy Writer e Checkpoint continuem trabalhando com páginas de dados somente em
memória e não sofram nenhum tipo de impacto com a implementação da nova arquitetura.  
Saiba mais
Para ver detalhes sobre o gerenciamento de memória do SQL Server, acesse o Guia de arquitetura de gerenciamento de
memória , da Microsoft, disponível em: https://docs.microsoft.com/pt-br/sql/relational-databases/memory-management-
architecture-guide?view=sql-server-ver15.
 Extensão do Buffer Pool
 Clique no botão acima.
Saiba mais
Veja uma comparação de velocidade, acessando SSD vs. HDD Speed.
javascript:void(0);
javascript:void(0);
/
Conclusão
Apresentamos os principais componentes do SQL Server e aprendemos como eles trabalham juntos para entregar o trabalho
que esperamos que um Sistema Gerenciador de Bancos de Dados realize.
Vimos como as solicitações chegam ao SQL Server por meio de pacotes TDS encapsulados em um dos protocolos disponíveis
na Protocol Layer. As mensagens com os comandos SQL são então encaminhadas ao Relational Engine para que seja realizado
o parsing. Se tudo estiver correto com o comando ele é transferido para o Optimizer, que vai gerar o plano de execução da
consulta e encaminhá-lo para o Query Executor.
Discutimos a importância do otimizador e a interface do Relational Engine com o Database Engine, componente que vai
providenciar o acesso aos dados, inicialmente através do Access Methods. Solicitações de leitura e escrita são encaminhadas
por ele ao Buffer Manager, que cuida especialmente das tarefas de gerenciamento do Buffer Pool, local na memória do servidor
em que são armazenadas as páginas de dados lidas do disco.
Caso a operação seja de atualização, esta é realizada primeiramente no arquivo de log de transações e somente depois, por
meio dos processos Lazy Writer e Checkpoint, é que elas efetivamente gravadas nos arquivos de dados. Com os resultados
obtidos nessa camada, estes são encaminhados de volta ao Query Executor que os encaminha então para a Protocol Layer. Os
dados são encapsulados em pacotes TDS e pelo canal de comunicação estabelecido com o cliente, o resultado é entregue.
 Um administrador do SQL Server é apresentado frequentemente a
novas questões sobre funcionalidades, operação e desempenho de
bancos de dados. Por isso é fundamental conhecer a arquitetura do
sistema. Conhecer o papel de cada componente e como se dá a
integração entre eles o fará compreender melhor o problema e chegar
mais rapidamente às conclusões.
Atividades
1. Qual dos seguintes componentes não faz parte da arquitetura do SQL Server?
a) Storage Engine
b) Buffer Pool
c)Protocol Layer
d) Relational Engine
e) Kernel Subsystem
/
2. Qual alternativa melhor descreve o objetivo principal do Relational Engine?
a) Receber as solicitações dos clientes, processá-las e enviar o resultado, na forma de mensagens TDS encapsuladas por pacotes TCP/IP.
b) Receber os comandos SQL e executar as operações de entrada e saída para gerar o resultado dos comandos.
c) Receber as solicitações da camada de serviço de rede e executar as operações necessárias para gerar o resultado esperado.
d) Receber os comandos SQL da camadade serviço de rede e construir um plano de execução para o comando, enviando-o para o
componente que vai de fato executar este último.
e) Receber as solicitações dos clientes e gerar um plano de execução para a solicitação, gerando os resultados e enviando-os de volta aos
clientes. 
3. Qual alternativa melhor expressa o objetivo principal do Storage Engine?
a) Receber as solicitações dos clientes vindas da camada de serviço de rede, executar críticas iniciais, processá-las e enviar o resultado de
volta para essa camada, para que retorne o resultado gerado para os clientes.
b) Receber as solicitações de leitura e escrita vindas do Relational Engine e executar as operações necessárias para gerar o resultado
esperado.
c) Receber os planos de execução oriundos do Relational Engine e processá-los de acordo com o método gerado pelo ACCESS METHODS
e utilizando o BUFFER MANAGER e o TRANSACTION MANAGER.
d) Receber as solicitações de leitura e escrita vindas do Relational Engine e construir um plano de execução para o comando, enviando-o
para o componente que vai de fato executar o comando.
e) Receber os planos de execução e os métodos de execução oriundos do Relational Engine e processá-los utilizando o BUFFER
MANAGER e o TRANSACTION MANAGER. 
4. Relacione as colunas a seguir de acordo com a integração entre os subsistemas que compõem a arquitetura do SQL Server.
Protocol Layer 1 Relational Engine 2 Storage Engine 3 Buffer Pool 4
a) Integra-se com o Relational Engine e com o Buffer Pool. Do
primeiro recebe os planos de execução e gera um método
associado, executando-o para gerar seu resultado. Para o
segundo, envia as solicitações de leitura de páginas de dados e,
após o devido tratamento realizado pelo Transaction Manager,
envia as solicitações de atualização de páginas de dados.
b) Integra-se com o Storage Engine, recebendo dele solicitação de
leitura e escrita de páginas de dados em memória.
c) Integra-se com o Relational Engine, enviando para ele os
comandos SQL contidos em pacotes TDS recebidos dos clientes.
d) Integra-se com o Protocol Layer e com o Storage Engine. Do
primeiro, recebe os comandos SQL para a geração de um plano
de execução. Para o segundo, envia esse plano e recebe o
resultado da sua execução.
/
5. Ordene os passos a seguir, executados em uma operação de leitura de dados.
A O Buffer Manager envia os dados solicitados para o Access Methods.
B O Command Parser veri�ca se já existe um plano de execução para o comando SQL.
C O Access Methods seleciona um método de execução para a leitura e encaminha para o Buffer Manager.
D A camada de serviço de rede recebe um pacote TDS contendo uma solicitação de um cliente.
E O otimizador gera um plano de execução para a Query Tree e o envia para o Query Executor.
F A camada de serviço de rede envia o comando SQL contido no pacote TDS do cliente para o Relational Engine.
G O Command Parser gera uma Query Tree e a envia para o otimizador.
H O Access Methods envia o resultado da consulta para o Query Executor para encaminhá-la ao cliente por meio da camada
de serviço de rede.
I O Query Executor con�rma que são necessários dados para atender à solicitação e encaminha o plano de execução para o
Access Methods, no Storage Engine.
J A camada de serviço de rede recebe um pedido de conexão de um cliente e a estabelece utilizando um dos protocolos
disponíveis.
K O Buffer Manager veri�ca se os dados requisitados já estão no Data Cache do Buffer Pool. Caso não estejam, o Buffer
Manager comanda uma solicitação de leitura de páginas de dados do disco e as adiciona no Buffer Pool.
L O Command Parser, módulo do Relational Engine, realiza um parser do comando.
Letra A
Letra B
Letra C
Letra D
Letra E
Letra F
Letra G
Letra H
Letra I
Letra J
Letra K
Letra L
/
6. Ordene os passos a seguir, executados em uma operação de escrita de dados, que ocorrem dentro do Storage Engine e do
Buffer Pool.
A O Access Methods encaminha uma solicitação de escrita para o Transaction Manager.
B O Access Methods encaminha uma solicitação de leitura ao Buffer Manager, para que este carregue os dados que serão
atualizados no Buffer Pool.
C O Access Methods encaminha uma solicitação de escrita para o Buffer Manager, para que este atualize os dados no Buffer
Pool.
D O Access Methods devolve o resultado para o Query Executor.
E O Access Methods recebe uma solicitação de escrita oriunda do Query Executor.
F O Transaction Manager adiciona registros no log de transações.
Letra A
Letra B
Letra C
Letra D
e) ALTERNATIVA
f) ALTERNATIVA
Notas
Páginas
É a menor unidade utilizada no armazenamento de dados.
Título modal 1
Lorem Ipsum é simplesmente uma simulação de texto da indústria tipográ�ca e de impressos. Lorem Ipsum é simplesmente
uma simulação de texto da indústria tipográ�ca e de impressos. Lorem Ipsum é simplesmente uma simulação de texto da
indústria tipográ�ca e de impressos.
Referências
ASSAF, W.; WEST, R.; AELTERMAN, S.; CURNUTT, M. SQL Server 2017 Administration Inside Out. Pearson Education, 2018.
 
DELANEY, K.; FREEDMAN, C. Microsoft SQL Server 2012 Internals. Microsoft Press, 2013.
 
MICROSOFT. Guia da arquitetura de processamento de consultas. 2020a. Disponível em: https://docs.microsoft.com/pt-
br/sql/relational-databases/query-processing-architecture-guide?view=sql-server-ver15. Acesso em: 21 maio 2020.
 
MICROSOFT. Guia de controle de versão de linha e bloqueio de transações. 2020b. Disponível em:
https://docs.microsoft.com/pt-br/sql/relational-databases/sql-server-transaction-locking-and-row-versioning-guide?view=sql-
server-ver15. Acesso em: 21 maio 2020.
 
MICROSOFT. SQL Server protocols. 2020c. Disponível em: https://docs.microsoft.com/en-
us/openspecs/sql_server_protocols/ms-sqlprotlp/f16558b2-4561-45be-89c9-6f9114514c97. Acesso em: 21 maio 2020.
javascript:void(0);
javascript:void(0);
javascript:void(0);
/
/ p p / q _ _p / q p p/
 
MICROSOFT. Guia de arquitetura de gerenciamento de memória. 2019a. Disponível em: https://docs.microsoft.com/pt-
br/sql/relational-databases/memory-management-architecture-guide?view=sql-server-ver15. Acesso em: 21 maio 2020.
 
MICROSOFT. Guia de arquitetura de página e extensões. 2019b. Disponível em: https://docs.microsoft.com/pt-
br/sql/relational-databases/pages-and-extents-architecture-guide?view=sql-server-ver15. Acesso em: 21 maio 2020.
 
MICROSOFT. Guia de arquitetura e gerenciamento do log de transações do SQL Server. 2019c. Disponível em:
https://docs.microsoft.com/pt-br/sql/relational-databases/sql-server-transaction-log-architecture-and-management-guide?
view=sql-server-ver15. Acesso em: 21 maio 2020.
 
MICROSOFT. Pontos de veri�cação de banco de dados (SQL Server). 2019d. Disponível em: https://docs.microsoft.com/pt-
br/sql/relational-databases/logs/database-checkpoints-sql-server?view=sql-server-ver15. Acesso em: 21 maio 2020.
MICROSOFT. Um guia para processamento de consulta de tabelas com otimização de memória. 2019e. Disponível em:
https://docs.microsoft.com/pt-br/sql/relational-databases/in-memory-oltp/a-guide-to-query-processing-for-memory-optimized-
tables?view=sql-server-ver15. Acesso em: 21 maio 2020.
 
MICROSOFT. Buffer Pool Extension. 2017. Disponível em: https://docs.microsoft.com/pt-br/sql/database-engine/con�gure-
windows/buffer-pool-extension?view=sql-server-ver15. Acesso em: 21 maio 2020.
 
RAMAKHRISHNAN, R.; GEHRKE, J. Database Management Systems. 3. ed. New York: Mcgraw-Hill, 2002.
 
RUBENS, P. SSD vs. HDD Speed. 2019. Disponível em: https://www.enterprisestorageforum.com/storage-hardware/ssd-vs-hdd-
speed.html. Acesso em: 21 maio 2020.
 
SRIVASTAVA, N. Microsoft SQL Server internal architecture for Database Engine. 2015. Disponível em:
https://uniqueblogforsqlcom.wordpress.com/2015/06/09/microsoft-sql-server-internal-architecture-for-database-engine/.
Acesso em: 21 maio 2020.
 
Próxima aula
Instalação do SQL Server no Windows, no Linux e no Docker;
javascript:void(0);
javascript:void(0);
javascript:void(0);