ROTINAS DO ADMINISTRADOR DO BANCO

DE DADOS

Curso: Administrador de Banco de Dados

Professor: Ralfe Della Croce Filho

Aluno: Stéfano Araujo Pereira

Rotinas de um Administrador de Banco de Dados............................................................................3
Infraestrutura recomendada para a instalação e configuração do SQL Server no sistema
operacional Windows........................................................................................................................ 3
Requisitos de hardware................................................................................................................. 3
Requisitos de software................................................................................................................... 4
Arquivos (dados, logs e demais informações) gerados pelo SQL Server e suas finalidades............4
Gerenciamento de usuários dos Bancos de Dados no SQL Server (autenticações e autorizações).
.......................................................................................................................................................... 4
Processos de Backup e Restore no SQL Server (tipos de backups e modos de recuperação de
dados). Procedimentos de segurança nos processos de backup e restore e com os arquivos de
backup gerados (garantia de integridade dos arquivos, compressão, criptografia)...........................5
Segurança no SQL Server:............................................................................................................... 6
Níveis de permissões........................................................................................................................ 6
Auditoria............................................................................................................................................ 6
Criptografia........................................................................................................................................ 6
Planos de Manutenção (tarefas agendadas, notificações e alertas para o DBA e demais
responsáveis).................................................................................................................................... 7
Replicação de dados......................................................................................................................... 7
Alta disponibilidade........................................................................................................................... 7
Performance...................................................................................................................................... 7
Testes de stress................................................................................................................................ 8
SQLStress......................................................................................................................................... 8
SQLQueryStress............................................................................................................................... 8
DTM DB Estresse.............................................................................................................................. 8
Plano de execução............................................................................................................................ 9
Boas práticas para querys performáticas.......................................................................................... 9
Índices............................................................................................................................................. 10
Estatísticas...................................................................................................................................... 10
Particionamentos............................................................................................................................. 11
Monitoramento dos bancos de dados (recursos do SQL Server e SSMS)......................................11
Ativity Monitor (Monitor de Atividade).............................................................................................. 12
Extended Events (Eventos estendidos)........................................................................................... 12
Data Collection (Coleta de dados)................................................................................................... 12
Query Store (Repositório de Consultas)..........................................................................................13
DMV (Views de gerenciamento dinâmico).......................................................................................13
Referências..................................................................................................................................... 14
Rotinas de um Administrador de Banco de Dados

Infraestrutura recomendada para a instalação e configuração do SQL Server no sistema

operacional Windows.

Requisitos de hardware

Os seguintes requisitos de memória e processador se aplicam a todas as edições do SQL Server:

Componente Requerimento

O SQL Server requer um mínimo de 6 GB de espaço disponível em disco

rígido.

Os requisitos de espaço em disco variam de acordo com os componentes do

Disco rígido SQL Server que você instala. Para obter mais informações,
consulte Requisitos de espaço em disco rígido mais adiante neste artigo. Para
obter informações sobre os tipos de armazenamento com suporte para
arquivos de dados, consulte Tipos de armazenamento para arquivos de
dados .

Monitor SQL Server requer Super-VGA (800x600) ou monitor de resolução superior.

A funcionalidade da Internet requer acesso à Internet (podem ser aplicadas

Internet
taxas).

Mínimo:

Edições Express: 512 MB

Todas as outras edições: 1 GB

Memória *
Recomendado:

Edições Express: 1 GB

Todas as outras edições: Pelo menos 4 GB e devem ser aumentadas à medida

que o tamanho do banco de dados aumenta para garantir o desempenho ideal.

Mínimo: x64 Processador: 1,4 GHz

Velocidade do
processador
Recomendado: 2,0 GHz ou mais rápido

Processador x64: AMD Opteron, AMD Athlon 64, Intel Xeon com suporte Intel
Tipo de processador
EM64T, Intel Pentium IV com suporte EM64T

O SQL Server tem os seguintes requisitos de sistema para Linux:

Requerimento

Memória 2 GB

Sistema de arquivo XFS ou EXT4 (outros sistemas de arquivos,

como BTRFS , não são suportados)

Espaço em disco 6 GB

Velocidade do processador 2 GHz

Processor cores 2 cores

Tipo de processador Apenas compatível com x64

Requisitos de software
Windows 10 TH1 1507 ou superior
Sistema operacional
Windows Server 2016 ou superior

Os sistemas operacionais mínimos incluem a

.NET Framework
estrutura .NET mínima.

Os sistemas operacionais com suporte para SQL

Server possuem software de rede integrado. As
instâncias nomeadas e padrão de uma instalação
Software de rede
autônoma suportam os seguintes protocolos de
rede: Memória compartilhada, Pipes nomeados e
TCP/IP.

Os seguintes requisitos se aplicam a todas as instalações no Linux:

O SQL Server é compatível com Red Hat Enterprise Linux (RHEL) (Servidor Red Hat Enterprise
Linux 8.0 - 8.5) e Ubuntu (Ubuntu 20.04 LTS). Também é compatível como uma imagem do
Docker, que pode ser executada no Docker Engine no Linux(Docker Engine 1.8+ no Linux).

Arquivos (dados, logs e demais informações) gerados pelo SQL Server e suas finalidades.

Primária (.mdf): Todo banco de dados possui um arquivo de dados primário. Contém informações
de inicialização do banco de dados e aponta para os outros arquivos no banco de dados.

Secundário (.ndf): Os dados podem ser distribuídos em vários discos, colocando cada arquivo em
uma unidade de disco diferente. Os Arquivos de dados são opcionais e definidos pelo usuário.

Log de Transações(ldf): Contém informações usadas para recuperar o banco de dados. Deve
haver, no mínimo, um arquivo de log para cada banco de dados.

Gerenciamento de usuários dos Bancos de Dados no SQL Server (autenticações e

autorizações).

A autenticação no SQL Server utiliza dois métodos de autenticação para autenticação para o
usuário se conectar a um banco de dados com uma conta de usuário.

Autenticação SQL: Nome de conta de usuário e uma senha associada é armazenada no banco
de dados mestre das contas de usuário vinculadas a um logon ou é armazenada no banco de
dados que contém as contas de usuário não vinculadas a um logon.

Autenticação do Azure Active Directory: Nome de conta de usuário e solicita que o serviço use
as informações de credenciais armazenadas no Azure Active Directory (Azure AD) ao usar esse
método de autenticação.

A autorização são gerenciadas pelas associações de função e permissões no nível do objeto do

banco de dados que devem concede privilégios de execução aos usuários.
Processos de Backup e Restore no SQL Server (tipos de backups e modos de recuperação
de dados). Procedimentos de segurança nos processos de backup e restore e com os
arquivos de backup gerados (garantia de integridade dos arquivos, compressão,
criptografia).

Backup completo: Contém todos os dados em um banco de dados específico ou um conjunto de

arquivos ou grupos de arquivos, e log para permitir a recuperação desses dados. É a base do
backup diferencial e do backup do log de transações. Deve haver um backup completo como base
para execução de backup diferencial.

Backup diferencial: O backup diferencial contém apenas os dados que foram alterados desde a
base diferencial. Normalmente, os backups diferenciais são menores e mais rápidos de criar do
que a base de um backup completo. O backup completo é restaurado primeiro, seguido pelo
backup diferencial mais recente que faz apenas o backup dos dados que foram alterados desde o
último backup completo.

Backup do log de transações: É um backup de logs de transações que inclui todos os registros
de log de transações foram executadas serialmente pelo banco de dados desde o último backup
do log de transações. Com esse tipo de backup é possível recuperar o banco de dados em um
ponto específico no tempo ou ainda em um ponto de falha. Cada backup de log cobre a parte do
log de transações que estava ativa quando o backup foi criado incluindo todos os registros de log
que não foram submetidos a backup em um backup de log anterior.

A estratégia de backup define o tipo e a frequência dos backups como os backups serão testados
e em que local e como a mídia de backup deve ser armazenada. Na restauração da estratégia
define responsabilidade para realizar restaurações, como devem ser executadas para atender às
disponibilidades do banco de dados e minimizar a perda de dados

Armazenamento separado: Coloque os backups de banco de dados em um local físico ou

dispositivo separado dos arquivos de banco de dados pois a recuperação depende da capacidade
de acessar a unidade separada ou o dispositivo remoto que armazenou os backups para executar
uma restauração.

Escolher o modelo de recuperação apropriado: As operações de backup e restauração

ocorrem dentro de um modelo de recuperação. O modelo de recuperação é de propriedade do
banco. Assim, o modelo de recuperação de um banco de dados determina quais tipos de backup e
cenários de restauração compatíveis com o banco de dados.

Planejar a estratégia de backup: Na manutenção de backups verifique se há uma agenda de

backup adequada e de acordo com os requisitos de negócios, quanto mais velhos, o risco de
perda de dados é maior. Estimar o tamanho do backup de banco de dados completo usando o
procedimento armazenado do sistema sp_spaceused referente ao Transact-SQL.

Agendar backups: A execução do backup tem um efeito mínimo sobre as transações em

andamento, portanto, as operações de backup podem ser realizadas durante a operação regular.
Você pode executar um backup do SQL Server com um efeito mínimo sobre as cargas de trabalho
de produção. Depois de decidir a frequência de execução de cada tipo, recomenda-se que seja
agendado os backups regulares como parte de um plano de manutenção de banco de dados.

Testar backups: É muito importante testar sua estratégia de backup completamente para cada
um dos bancos de dados, restaurando uma cópia do banco de dados em um sistema de teste. É
necessário testar a restauração de cada tipo de backup que você pretende usar e também verificar
a consistência do banco de dados usando DBCC CHECKDB para saber se a mídia de backup não
foi danificada.

Documentar estratégia de backup/restauração: Documente seus procedimentos de backup e

restauração e mantenha uma cópia da documentação em seu livro de execuções. Crie o manual
de operações para cada banco de dados, onde deve documentar o local dos backups, os nomes
do dispositivo de backup (se houver) e o tempo necessário para restaurar os backups de teste. 
Monitorar o progresso com xEvent Operações de backup e restauração podem levar um tempo
considerável devido ao tamanho de um banco de dados e à complexidade das operações, quando
ocorrem problemas com a operação, você pode usar o evento estendido
backup_restore_progress_trace para monitorar o progresso em tempo real.

Criptografia: No SQL Server, as chaves de criptografia incluem uma combinação de chaves

públicas, privadas e simétricas que são usadas para proteger dados confidenciais. Esta seção
explica como implementar e gerenciar chaves de criptografia.

Segurança no SQL Server:

A segurança no acesso às informações significa que o usuário deve ser capaz de acessar os
dados necessários com nível de acesso suficiente, para que o usuário realize seu trabalho.
Através do mecanismo de segurança também evitamos que pessoas não autorizadas tenham
acesso aos dados.

Níveis de permissões.
O SQL Server fornece funções do nível de servidor para ajudar a gerenciar as permissões em um
servidor. Estas funções são entidades de segurança que agrupam outras entidades de segurança.
Essas funções abrangem todo o servidor em seus escopos de permissões. No sistema
operacional Windows as funções são como grupos no sistema. A verificação de permissões pode
ser uma tarefa complexa. O algoritmo de verificação de permissão inclui a sobreposição de
associações de grupo e o encadeamento de propriedades, as permissões explícita e implícita, e
pode ser afetado pelas permissões em classes de protegíveis que contêm a entidade protegível. O
algoritmo contém três elementos essenciais: o contexto de segurança, o espaço de permissão e a
permissão necessária.

Auditoria.
A auditoria de uma instância do Mecanismo de Banco de Dados do SQL Server ou de um banco
de dados individual envolve o controle e o registro em log dos eventos que ocorrem no Mecanismo
de Banco de Dados. A auditoria do SQL Server permite criar auditorias de servidor, que podem
conter especificações de auditoria de servidor para eventos no nível de servidor, além de
especificações de auditoria de banco de dados para eventos no nível de banco de dados. Os
eventos auditados podem ser gravados nos logs de eventos ou nos arquivos de auditoria.

O objeto Auditoria do SQL Server coleta uma instância única de ações no nível do servidor e/ou do
banco de dados e grupos de ações a serem monitoradas. A auditoria está no nível de instância do
SQL Server. Você pode ter várias auditorias por instância do SQL Server.

Quando você está salvando informações de auditoria em um arquivo, para ajudar a impedir
falsificação, você pode restringir o acesso ao local do arquivo das seguintes maneiras:

 A Conta de Serviço SQL Server deve ter permissão de Leitura e Gravação.

 Os Administradores de Auditoria geralmente requerem permissão de Leitura e Gravação.
Isso pressupõe que os Administradores de Auditoria sejam contas do Windows para a
administração de arquivos de auditoria, por exemplo, copiando-os em compartilhamentos
diferentes, armazenandoos em backup e assim por diante.
 Os Leitores de Auditoria que são autorizados a ler os arquivos de auditoria precisam ter
permissão de Leitura. Mesmo quando o Mecanismo de Banco de Dados estiver gravando
em um arquivo, outros usuários do Windows poderão ler o arquivo de auditoria se tiverem
permissão. O Mecanismo de Banco de Dados não possui um bloqueio exclusivo que
impeça operações de leitura.

Criptografia.
Em SQL Server, as chaves de criptografia incluem uma combinação de chaves públicas, privadas
e simétricas que são usadas para proteger dados confidenciais. Esta seção explica como
implementar e gerenciar chaves de criptografia. O SQL Server, dispõe de recursos que auxiliam
na criptografia de dados armazenados nas tabelas, bem como na obtenção da informação original
após reverter o processo/descriptografia.

Planos de Manutenção (tarefas agendadas, notificações e alertas para o DBA e demais

responsáveis).

Os planos de manutenção criam um fluxo de trabalho das tarefas necessárias para garantir que o
banco de dados seja otimizado, armazenado regularmente em backup e livre de inconsistências.

Existe a ferramenta de Assistente de Plano de Manutenção cria um plano de manutenção que

pode ser executado regularmente pelo Microsoft SQL Server Agent. Isso permite executar várias
tarefas de administração de banco de dados, incluindo backups, verificações de integridade de
banco de dados ou atualizações de estatísticas de banco de dados em intervalos especificados.

Replicação de dados

O espelhamento do banco de dados pode ser usado junto com a replicação para aprimorar a
disponibilidade ao banco de dados de publicação. O espelhamento do banco de dados
compreende duas cópias de um único banco de dados que geralmente reside em computadores
diferentes. Em determinado momento, apenas uma cópia do banco de dados está atualmente
disponível aos clientes. Essa cópia é conhecida como o banco de dados principal. As atualizações
realizadas pelos clientes no banco de dados principal são aplicadas à outra cópia do banco de
dados, conhecida como banco de dados espelho. O espelhamento envolve a aplicação do log de
transações de cada inserção, atualização ou exclusão efetuada no banco de dados principal, para
o banco de dados espelho.

O failover de replicação para um espelho tem o suporte total para os bancos de dados de
publicação, com suporte limitado para bancos de dados de assinatura. O espelhamento de banco
de dados não tem suporte para bancos de dados de distribuição. Para obter informações sobre
como recuperar um banco de dados de distribuição ou banco de dados de assinatura sem precisar
reconfigurar a replicação

Alta disponibilidade.

O sistema de alta disponibilidade é aquele que permanece disponível a maior parte do tempo,
minimizando ao máximo riscos de parada do sistema. Como muitos sistemas de informação têm
como elemento central bancos de dados relacionais, a continuidade dos negócios depende da
disponibilidade destes bancos.

Um sistema de gerenciamento de banco de dados depende de vários componentes de hardware e

software para rodar e a alta disponibilidade é conseguida com redundâncias que tentam eliminar
pontos únicos de falha (Single Point Of Failure - SPOF) de cada componente do sistema.

Os bancos de dados que contêm tabelas com otimização de memória, com ou sem procedimentos
armazenados compilados nativos, são totalmente compatíveis com Grupos de Disponibilidade
AlwaysOn. Não há nenhuma diferença na configuração e no suporte de bancos de dados que
contêm objetos do OLTP na memória em comparação aos que não têm. Configurar bancos de
dados com componentes OLTP na memória fornece os seguintes benefícios: Uma experiência
totalmente integrada, Tempo de Failover comparável e Secundária Legível

Performance
A meta do monitoramento de bancos de dados é avaliar o desempenho do servidor. Um
monitoramento eficaz envolve a criação de instantâneos periódicos do desempenho atual para
isolar processos que estão ocasionando problemas, e a coleta contínua de dados para o controle
das tendências de desempenho.
 A avaliação contínua do desempenho de banco de dados ajuda a minimizar tempos de resposta e
a maximizar a taxa de transferência, permitindo alcançar desempenho ótimo. Tráfego de rede, E/S
de disco e uso de CPU eficientes são fundamentais para um desempenho ótimo. É preciso
analisar minuciosamente os requisitos de aplicativos, compreender a estrutura lógica e física dos
dados, avaliar o uso de banco de dados e negociar compensações entre usos conflitantes, tais
como a do processamento de transações online (OLTP) versus o apoio à decisão.

O SQL Server Management Studio fornece a capacidade de exibir o plano de execução ao vivo de
uma consulta ativa. Esse plano de consulta dinâmica fornece informações em tempo real sobre o
processo de execução da consulta, conforme os controles fluem de um operador de plano de
consulta para outro.

O plano de consulta ao vivo exibe o progresso geral da consulta e as estatísticas de tempo de

execução do nível de operador, como o número de linhas produzido, tempo decorrido, progresso
do operador, etc. Como esses dados estão disponíveis em tempo real sem a necessidade de
aguardar a conclusão da consulta, essas estatísticas de execução são extremamente úteis para
depurar problemas de desempenho de consulta.

Testes de stress.
Um servidor SQL é um servidor de banco de dados, o que significa que ele oferece banco de
dados, ou seja, várias coleções de dados classificados, serviços de programas de software e
estações de trabalho de computador. Programas de testes de stress do servidor SQL determinar o
quão bem o servidor pode realizar durante as cargas de trabalho normais e pesados.
Basicamente, estes testes determinam se ou não o servidor é suficientemente estável para fazer
as tarefas a que foi realizado para fazer.

SQLStress
Projetada para carregar consultas individuais de teste. Ele inclui suporte para randomização de
parâmetros de entrada para testar a repetibilidade do cache e inclui recursos básicos para
relatórios sobre recursos de servidor consumidos. É uma ferramenta gratuita que testa o processo
de instalação do Microsoft SQL Server, ajuda a determinar se há ou não nada de errado com a
infraestrutura da instalação. Podendo ser usado também para testar o quão bem o seu servidor de
jogos até os padrões da indústria e para testar o dimensionamento de hardware.
Dimensionamento de hardware refere-se aos recursos mínimos necessários para executar um
determinado programa de software.

SQLQueryStress
Esta é uma ferramenta gratuita que permite que você faça testes de estresse em consultas T-SQL.
A Transact-SQL é uma instrução que permite que os aplicativos para se comunicar com o servidor
SQL. Uma consulta procura bancos de dados como o servidor SQL para os critérios de palavras-
chave específicas. A ferramenta permite que você SQLQueryStress determinar quão estável suas
consultas são quando colocado sob um monte de estresse ou de carga pedidos. Ele também irá
ajudá-lo a determinar quais os recursos colocar mais pressão sobre o sistema. Esta informação
será emitida ao SQL Server na forma de estatísticas. Pode salvar todas as consultas que foram
executadas anteriormente. Essas consultas podem demorar um pouco para configurar, e esta
ferramenta ajuda a eliminar a necessidade de criação de consultas que serão usadas mais de uma
vez. A ferramenta SQLQueryStress usa um formato de assistente para ajudá-lo através do
processo de criação da consulta.

DTM DB Estresse
É uma ferramenta de utilitário que permite o teste em algumas partes do seu servidor ou do
servidor inteiro. Permite enviar os seguintes pedidos usando esta ferramenta de teste de estresse:
OLAP (processamento analítico online) e OLTP (processamento de transações on-line). O OLAP
permite analisar rapidamente os dados coletados a partir de consultas. O OLTP é um processo do
sistema que supervisiona os processos de transação como entrada de dados, ou procurar e
encontrar processos. O estresse DTM DB informações de saída tanto em formato HTML
(Hypertext Markup Language) ou Microsoft Excel formatos de texto. Esta ferramenta é compatível
com o Windows Server 2003, Server 2008, XP, Vista ou 7 e com ambos os sistemas x64, mas
para obter esta edição os usuários interessados terão primeiro entrar em contato com a empresa.

Plano de execução.
Exibe de maneira gráfica os métodos de recuperação de dados que o otimizador de consulta do
SQL Server escolheu. Além de mostrar também o custo (em termos de uso de recursos) da
execução das instruções. Permitindo enxergar as etapas de execução da uma query e assim
verificar o que pode ser melhorado, além de ter como outra utilidade a comparação entre duas
queries. É uma boa prática verificar se o plano de consulta da nova query é melhor que o plano de
consulta da query anterior. Para poder executar consultas, o Mecanismo de Banco de Dados do
SQL Server deve analisar a instrução para determinar a maneira mais eficiente de acessar os
dados necessários. Essa análise é tratada por um componente chamado de Otimizador de
Consulta. A entrada do Otimizador de Consulta consiste em uma consulta, o esquema de banco
de dados (definições de tabela e de índice) e as estatísticas de banco de dados. A saída do
Otimizador de Consulta é um plano de execução de consulta, às vezes chamado de plano de
consulta ou plano de execução.

SQL Server Management Studio tem três opções para exibir os planos de execução:

 O Plano de Execução Estimado é o plano compilado, como produzido pelo Otimizador de

Consulta com base em estimativas. Esse é o plano de consulta armazenado no cache de
planos.
 O Plano de Execução Real - é o plano compilado mais o contexto de execução. Ele ficará
disponível depois que a execução da consulta tiver sido concluída. Inclui informações de
runtime como avisos de execução ou, em versões mais recentes do Mecanismo de Banco
de Dados, o tempo decorrido e o tempo de CPU usados durante a execução.
 As Estatísticas de Consulta Dinâmica - são o plano compilado mais o contexto de
execução. Estão disponíveis para execuções de consulta em andamento e são
atualizadas a cada segundo. Isso inclui informações de runtime, como o número real de
linhas fluindo pelos operadores, tempo decorrido e progresso estimado da consulta.

Boas práticas para querys performáticas.

Cuidados precisam ser tomados ao escrever uma query, dentre eles podemos citar:

1. Favoreça a lógica de conjuntos ao invés da lógica de procedimentos;

2. Teste variações de queries objetivando a performance;

3. Evite QUERY HINTS (dar dica ao banco sobre qual índice ele deve usar);

4. Use subqueries correlatas;

5. Evite funções definidas pelo usuário na cláusula WHERE;

6. Use funções tabulares como tabelas derivadas;

7. Evite colunas GROUP BY desnecessárias;

8. Use expressões CASE;

9. Divida JOINS em tabelas temporárias.

10. Não utilizar HINTS;

11. Não mexer no mecanismo de LOCK;

12. Exigir uma política de desenvolvimento para todos seguirem;

13. Deve mexer no nível de isolamento de transação;

14. Sempre utilizar FULL QUALIFIED NAME. Use FROM db_banco_teste.dbo.cidade ao invés de
from cidade;

15. Evitar o famoso SELECT asterisco, e colocar somente o nome das colunas que desejar que o
banco retorne;

16. Ter cautela com SUBQUERIES. Procurar sempre que possível trocá-las por Joins. A cláusula
EXISTS com SUBQUERIES será uma exceção;

17. Raciocinar sempre em trabalhar com conjuntos de dados e nunca unitariamente, isto é, pensar
em conjuntos de dados e não em registros;

18. Deve ter uma PRIMARY KEY (preferencialmente, está sendo um índice clusterizado, pois toda
tabela precisa ter no mínimo um índice destes) em todas as tuas tabelas;

19. Dever ter uma quantidade apropriada de índices não clusterizados em todas as tabelas. Estes
deverão ser criados nas colunas de uma tabela devido à necessidade de uma QUERY que esteja
sendo colocada em produção;

20. Adotar a seguinte ordem de prioridade quando qualquer índice for criado: a. Cláusula WHERE;
b. Cláusula JOIN; c. Cláusula ORDER BY; d. Cláusula SELECT.

21. Remover qualquer JOIN desnecessário das consultas;

22. Evitar o uso de VIEWS (geralmente são lentas e reduzem a performance);

23. Verificar se o HD do servidor de banco de dados possui pelo menos 30% de espaço livre. Isto
garante um pouco de performance. Fazer o ajuste (tunning) de uma consulta é muito importante,
pois são vários sintomas e indicadores que devem ser analisados antes de tomar qualquer
decisão.

Índices.
Um índice é uma estrutura em disco associada a uma tabela ou view, que agiliza a recuperação
das linhas. Um índice contém chaves criadas de uma ou mais colunas e essas chaves são
armazenadas em uma estrutura (árvore B) que habilita o SQL Server a localizar a linha ou as
linhas associadas aos valores de chave de forma rápida e eficaz.

Com a criação do índice, o banco de dados irá criar uma estrutura de árvore ordenada para
facilitar as buscas, onde o primeiro nível é a raiz, os níveis intermediários contêm as árvores de
índices e o último nível contém os dados e uma lista duplamente encadeada ligando as páginas de
dados, contendo um ponteiro de página anterior e próxima página.

Nem sempre o uso de índice trará um bom desempenho, pois a escolha incorreta de um índice
pode causar um desempenho insatisfatório. Portanto, a tarefa do otimizador de consulta é
selecionar um índice ou uma combinação de índices apenas quando isso gerar melhoria de
desempenho e evitar a recuperação indexada quando isso atrapalhar o desempenho.

Estatísticas.
São objetos que detêm informações importantes sobre a distribuição dos dados dentro de tabelas
e views indexadas. As estatísticas são de extrema importância para o SQL Server, uma vez que o
Otimizador de Consulta utiliza as estatísticas para analisar a seletividade e cardinalidade dos
dados, a fim de criar um plano de alta qualidade traçando a melhor “rota” para execução da query.

Internamente as estatísticas são divididas em três partes:

O cabeçalho que contém os metadados referentes à estatística em questão.

Um histograma que é a parte mais importante, onde armazena os valores de distribuição referente
à primeira coluna da chave da tabela ou view indexada.

Um vetor de densidade utilizado para medir e manipular a correlação entre as colunas. Toda
consulta executada no SQL Server deve gerar um plano de execução, o que nada mais é do que
uma sequência de operações para retornar determinado resultado. O plano de execução utiliza as
estatísticas como input de dados para analisar informações como seletividade, quantidade de
linhas e números de páginas utilizados pela tabela.

Por padrão, ao criar um banco de dados, a opção AUTO_CREATE_ STATISTICS vem

configurada como ON, garantindo a criação de estatísticas sempre que necessário. O SQL Server
cria estatística para tudo, toda operação usada para manipular dados está passiva de uma
geração de estatística, assim como toda consulta gera um plano de execução e todo plano de
execução baseia-se em estatística para analisar o custo da operação, definindo assim quais
operadores e índices serão utilizados para retornar os dados da forma mais performática possível.

Existem três formas de uma estatística ser criada: automática, explicita e implicitamente.

Estatísticas automáticas – a configuração AUTO_CREATE_ STATISTICS por default é ON. Isso

permite que, caso necessário, o SQL Server crie estatísticas em operações de manipulação de
dados. Ao executar o SELECT, teoricamente forçará o SQL Server a criar um plano de execução e
como não existe nenhuma estatística para a tabela, internamente e automaticamente será criada
para o predicado.

Estatísticas criadas implicitamente – acontece quando um índice é criado – seja ele clustered
ou não – e por consequência são criadas estatísticas implicitamente para os campos chaves do
índice. Adicionando uma PK a tabela, um índice também é criado e implicitamente a estatística foi
gerada para a chave do índice.

Estatísticas criadas manualmente – para cria-las manualmente utiliza-se o comando CREATE

STATISTICS. Por default, a configuração AUTO_UPDATE_STATISTICS é configurada como ON,
garantindo por meio de monitoramento das modificações a atualização periódica das estatísticas.
O SQL Server utiliza uma lógica baseando-se na quantidade de alterações efetuadas na tabela.
Ou seja, existe uma regra para atualização e quando o limite de alteração é atingido, a estatística
é atualizada. A atualização das estatísticas é de suma importância, pois como foi dito
anteriormente, o plano de execução utiliza as estatísticas para avaliar o custo da query.
Estatísticas desatualizas podem gerar planos ineficientes impactando na performance da query.

Particionamentos
É o recurso no qual o administrador de banco de dados poderá ter o domínio dos locais onde seus
dados são armazenados. Atualmente, não utilizando esta funcionalidade, podemos determinar em
qual diretório ou diretórios os arquivos de filegroup ficarão armazenados. Com o particionamento
dos dados, é possível ter um gerenciamento melhor dos dados, ganhando em performance e
também acompanhando em que partição/filegroup o registro está alocado.

Os dados são particionados horizontalmente, de forma que os grupos de linhas são mapeados em
partições individuais. Todas as partições de um único índice ou de uma única tabela devem residir
no mesmo banco de dados. A tabela ou o índice é tratado como uma única entidade lógica quando
são executadas consultas ou atualizações nos dados.

O mecanismo de banco de dados dá suporte a até 15.000 partições por padrão. Em versões
anteriores à SQL Server 2012 (11.x), o número de partições era limitado por padrão a 1.000.

Monitoramento dos bancos de dados (recursos do SQL Server e SSMS).

O Microsoft SQL Server fornece um conjunto abrangente de ferramentas para monitorar eventos
no SQL Server e ajustar o design do banco de dados físico. A escolha da ferramenta depende do
tipo de monitoramento ou de ajuste a ser feito e dos eventos em particular a monitorar.

Alguns exemplos são: Funções internas (Transact-SQL), DBCC (Transact-SQL), Orientador de

Otimização do Mecanismo de Banco de Dados (DTA), DEA (Assistente para Experimentos de
Banco de Dados), Logs de erros, Eventos estendidos, etc.

O Painel de Desempenho ajuda a identificar rapidamente se SQL Server ou Banco de Dados SQL
do Azure está passando por um gargalo de desempenho. Se for encontrado um gargalo, capture
facilmente dados de diagnóstico adicionais que podem ser necessários para resolver o problema.
O Painel de Desempenho também ajuda a identificar consultas dispendiosas executadas antes e
várias métricas estão disponíveis para definir o alto custo: CPU, Gravações Lógicas, Leituras
Lógicas, Duração, Leituras Físicas e Tempo do CLR.

Ativity Monitor (Monitor de Atividade).

O Monitor de Atividade é uma janela do documento com guias com os seguintes painéis
expansíveis e recolhíveis: Visão geral, Processos, Esperas Recentes, E/S do Arquivo de Dados,
Consultas Caras Recentes e Consultas Caras Ativas.

O Monitor de Atividade consulta a instância para obter informações sempre que qualquer painel
seja expandido. Podendo ser expandido um ou mais painéis ao mesmo tempo para a exibição de
diferentes tipos de atividade na instância. Quando um painel é recolhido, todas as atividades de
consulta são interrompidas para esse painel.

O Monitor de Atividade no SSMS (SQL Server Management Studio) exibe informações sobre os
processos do SQL Server e como esses processos afetam a instância atual do SQL Server. Ele
executa consulta na instância monitorada com o propósito de obter informações para os painéis de
exibição do Monitor de Atividade. Quando o intervalo de atualização for definido para menos de 10
segundos, o tempo usado para executar essas consultas poderá afetar o desempenho do servidor.

Para que a atividade atual seja exibida, é necessário ter a permissão VIEW SERVER STATE.
Para exibir a seção E/S de Arquivo de Dados do Monitor de Atividade, é necessário ter a
permissão CREATE DATABASE, ALTER ANY DATABASE ou VIEW ANY DEFINITION além da
permissão VIEW SERVER STATE.

Para ENCERRAR um processo, o usuário precisa ser um membro das funções de servidor fixas
SYSADMIN ou PROCESSADMIN.

Extended Events (Eventos estendidos).

O SQL Server Extended Events é uma ferramenta de monitoramento de desempenho que ajuda a
coletar e monitorar as ações do mecanismo de banco de dados para diagnosticar problemas no
SQL Server.

O principal problema do profiler estava relacionado ao desempenho, pois consome muitos

recursos do sistema, e essa situação estava afetando negativamente o desempenho do banco de
dados. Os eventos estendidos do SQL Server não afetam o desempenho do SQL Server como faz
o criador de perfil e também oferece vários eventos que ajudam a solucionar problemas de
desempenho da consulta e outros problemas.

Data Collection (Coleta de dados).

O Coletor de Dados é um componente do SQL Server que coleta diferentes conjuntos de dados. A
coleta de dados é executada constantemente ou em uma agenda definida pelo usuário. O mesmo
armazena os dados coletados em um banco de dados relacional conhecido como data Warehouse
de gerenciamento. É integrado ao SQQL Server Agent e ao Integration Services, utilizando-os
extensivamente. Antes de trabalhar com o coletor de dados é necessário entender determinados
conceitos relacionados a cada um desses componentes do SQL Server.

O SQL Server Agent é usado para programar e executar trabalhos de coleta. E para isso é preciso
entender os seguintes conceitos:

 Trabalho
 Etapa de trabalho
 Agenda do trabalho
 Subsistema
 Contas Proxy
O Integration Services (SSIS) é usado para executar pacotes que coletam dados de provedores de
dados individuais. Você precisa estar familiarizado com as seguintes ferramentas e conceitos do
SSIS :

 Pacote SSIS
 Configuração do pacote SSIS

Os conjuntos de coleta são definidos e implantados em uma instância de servidor e podem ser
executados independentemente um do outro. Cada conjunto de coleta pode ser se aplicado a um
destino que corresponda aos tipos de destino de todos os tipos de coletor que fazem de um
conjunto de coleta. O conjunto de coleta é executado por um trabalho ou trabalhos do SQL Server
Agent, e os dados são carregados no data warehouse de gerenciamento em uma agenda
predefinida.

Query Store (Repositório de Consultas).

O Query Store é um repositório de consultas, onde registra em memória informações sobre os
planos de execução de uma query, para depois persistir em disco. Existem várias formas de
análise de planos de execução para se obter uma melhor performance e desempenho na consulta
de uma query. A mesma pode ter vários planos de execução por vários motivos.

O Query Store possibilita fazer uma análise nos planos de execução gerados, permitindo ao DBA
a opção de escolher qual o melhor plano para a execução de uma query, obtendo uma melhor
performance, podendo, inclusive, fazer uma regressão de algum plano, caso seja necessário, ou
seja, podemos forçar um plano de execução se necessário.

Vantagens em utilizar o Query Store:

 Auxilia no processo de migração de uma versão

 Mantém o histórico dos planos de execução, mesmo após um reinício do SQL Server
 Consome somente os recursos configurados
 Possui 19 extend events específicos para o Query Store.

DMV (Views de gerenciamento dinâmico).

Views de gerenciamento dinâmico (também chamado de DMV) são o conjunto de informações que
retratam o comportamento do ambiente do banco de dados, mostrando ao DBA informações sobre
diversas situações como índices ausentes, espaço armazenado pelos objetos, consultas que
estão consumindo mais recursos, entre outras informações.

Os dados das DMVs iniciam sua coleta de informações a partir do momento em que o serviço do
SQL Server é iniciado, gravando todas as informações não em tabelas físicas, mas em estruturas
internas do servidor.

As exibições e funções de gerenciamento dinâmico retornam informações do estado do servidor

que podem ser usadas para monitorar a saúde da instância do servidor, diagnosticar problemas e
ajustar o desempenho.

Estas DMVs auxiliam na administração do ambiente, fazendo com que o DBA trabalhe com
informações consistentes, mostrando desde o comportamento do sistema operacional (SO) até
informações sobre consultas que estão consumindo muito recurso e que talvez precisem de uma
análise mais detalhada para se inserir um índice.

Há dois tipos de exibições e funções de gerenciamento dinâmico: Exibições e funções de

gerenciamento dinâmico de escopo de servidor. Requerem a permissão VIEW SERVER STATE
no servidor.Exibições e funções de gerenciamento dinâmico de escopo de banco de dados.
Requerem permissão VIEW DATABASE STATE no banco de dados.

É importante saber que elas retornam dados de estado internos específicos de implementação, os
esquemas e os dados retornados podem mudar em versões futuras do SQL Server. Por isso, as
exibições e funções de gerenciamento dinâmico, em versões futuras, podem não ser compatíveis
com as exibições e funções de gerenciamento dinâmico nessa versão. A Microsoft em versões
futuras do SQL Server poderá aumentar a definição de qualquer exibição do gerenciamento
dinâmico adicionando colunas ao final da lista de colunas. Salientando que não se recomenda o
uso da sintaxe SELECT * FROM dynamic_management_view_name no código de produção, pois
o número de colunas retornado pode mudar e quebrar seu aplicativo.

Referências
https://www.microsoft.com/en-us/sql-server/sql-server-downloads

https://docs.microsoft.com

https://docs.microsoft.com/pt-br/sql/sql-server/install/hardware-and-software-requirements-for-
installing-sql-server-2019?view=sql-server-ver16

https://www.devmedia.com.br/manipulacao-de-arquivos-de-dados-e-log-no-sql-server/33623

https://docs.microsoft.com/pt-br/azure/azure-sql/database/logins-create-manage?view=azuresql

https://roxpartner.com/backup-e-recuperacao-no-sql-server/

https://docs.microsoft.com/pt-br/sql/relational-databases/security/encryption/sql-server-encryption?
view=sql-server-ver16

https://docs.microsoft.com/pt-br/sql/database-engine/database-mirroring/database-mirroring-and-
replication-sql-server?view=sql-server-ver16

https://www.devmedia.com.br/alta-disponibilidade-no-sql-server/33296

https://docs.microsoft.com/pt-br/sql/sql-server/install/hardware-and-software-requirements-for-
installingsql-server?view=sql-server-ver16

https://imasters.com.br/data/como-ler-e-interpretar-os-logs-sql-server-parte-01

https://br.easeus.com/backup-recovery/tipos-de-backup-dosql.html#:~:text=Tr%C3%AAs%20Tipos
%20de%20Backup%20do,Backup%20do%20Log%20de%20Transa%C3
%A7%C3%B5es&text=Fa%C3%A7a%20backup%20e%20restaure%20arquivos,ou%20transferir
%20seu%20sist ema%20rapidamente.