0% acharam este documento útil (0 voto)
0 visualizações4 páginas

Performance Tuning SQL Server

Enviado por

faustocrbl
Direitos autorais
© All Rights Reserved
Levamos muito a sério os direitos de conteúdo. Se você suspeita que este conteúdo é seu, reivindique-o aqui.
Formatos disponíveis
Baixe no formato PDF, TXT ou leia on-line no Scribd
0% acharam este documento útil (0 voto)
0 visualizações4 páginas

Performance Tuning SQL Server

Enviado por

faustocrbl
Direitos autorais
© All Rights Reserved
Levamos muito a sério os direitos de conteúdo. Se você suspeita que este conteúdo é seu, reivindique-o aqui.
Formatos disponíveis
Baixe no formato PDF, TXT ou leia on-line no Scribd

Estudo Avançado 1:

Performance Tuning e Otimização


de Consultas no SQL Server
Guia Completo de Arquitetura, Índices e Diagnóstico de
Performance

Autor: Especialista DBA & Engenharia de Dados


Tecnologia: Microsoft SQL Server 2022 / 2026
Data: Junho de 2026
Status: Documento Técnico de Referência
Estudo Dirigido - SQL Server

Módulo 1: A Arquitetura Profunda do Mecanismo de Banco de


Dados
Para executar o tuning de forma verdadeiramente eficiente no Microsoft SQL Server, é mandatório
compreender a mecânica interna que governa a execução de cada instrução Transact-SQL (T-SQL). O
mecanismo divide-se primordialmente em dois componentes vitais: o Relational Engine (mecanismo
relacional) e o Storage Engine (mecanismo de armazenamento).

1.1 Relational Engine vs. Storage Engine

O Relational Engine, também conhecido como Query Processor, gerencia o ciclo de processamento lógico de
uma consulta. Suas etapas essenciais incluem:

• Parsing: Validação da sintaxe T-SQL. Se a estrutura estiver correta, cria-se uma Parse Tree.

• Binding / Alocação (Normalization): Verificação semântica dos nomes de objetos e colunas contra o
catálogo do sistema, checando permissões de segurança.

• Optimization: O Query Optimizer avalia múltiplos planos possíveis usando estatísticas de distribuição de
dados e decide o plano de menor custo estimado.

Por outro lado, o Storage Engine lida com as estruturas físicas de armazenamento, controle de concorrência,
travas (locks/latches) e transações (através do Write-Ahead Logging).

Nota Arquitetural Importante

Toda leitura de dados no SQL Server ocorre estritamente através da memória (Buffer Pool). Se uma
página de dados de 8KB não estiver em memória, o Storage Engine emite uma requisição física de I/O
para o subsistema de discos.

1.2 Buffer Pool e Gerenciamento de Memória

O Buffer Pool é o maior consumidor de memória do SQL Server. A eficiência da leitura reside no reuso de
páginas. Quando ocorre um Page Fault, a página é copiada do disco para o Buffer Pool. O componente Lazy
Writer varre periodicamente o buffer limpando páginas antigas não modificadas ou gravando páginas sujas
(dirty pages) de forma assíncrona para liberar espaço.

Módulo 2: Desvendando o Execution Plan (Plano de Execução)


O plano de execução gráfica ou XML é o diagnóstico mais rico disponível para um desenvolvedor ou DBA.

Página 2
Estudo Dirigido - SQL Server

2.1 Plano Estimado vs. Plano Real

O Plano Estimado é gerado puramente pelo Optimizer baseado nas estatísticas, sem de fato rodar a
consulta. O Plano Real traz os contadores de tempo real, linhas processadas e número de execuções de
cada operador. Em ambientes produtivos altamente concorridos, a coleta massiva de planos reais pode gerar
sobrecarga, devendo ser feita de modo cirúrgico.

2.2 Principais Operadores de Leitura

Operador Tipo de Estrutura Descrição Teórica e Impacto

Leitura completa linha por linha. Altamente ineficiente para tabelas


Table Scan Heap (Sem Índice)
volumosas.

Clustered Varredura completa da árvore de índices. Significa que o SQL Server


B-Tree Clusterizada
Index Scan leu a tabela inteira estruturada.

Clustered Busca cirúrgica descendo os níveis da árvore. O cenário ideal de


B-Tree Clusterizada
Index Seek performance.

Não-Clusterizado para Ocorre quando um índice não-clusterizado satisfaz o filtro, mas


Key Lookup
Clusterizado faltam colunas no SELECT, obrigando a buscar na tabela base.

Módulo 3: Estratégias Avançadas de Indexação


Índices bem desenhados reduzem drasticamente o consumo de CPU e I/O. Um índice mal desenhado
penaliza as operações de escrita (INSERT, UPDATE, DELETE).

3.1 Índices Cobertos (Covering Indexes)

Para mitigar o gargalo de Key Lookups, utilizamos a cláusula INCLUDE. Esta estratégia adiciona colunas de
dados diretamente no nível folha do índice não-clusterizado, eliminando a necessidade de consultar a tabela
primária.

3.2 Manutenção e Fragmentação

Conforme dados são inseridos e modificados, ocorrem os chamados Page Splits, gerando fragmentação
física e lógica. A regra geral da Microsoft recomenda:

• Fragmentação entre 5% e 30%: Executar ALTER INDEX REORGANIZE (operação online, leve).

• Fragmentação acima de 30%: Executar ALTER INDEX REBUILD (recriação total, pesada).

Página 3
Estudo Dirigido - SQL Server

Módulo 4: Códigos Práticos de Diagnóstico (Scripts T-SQL)


Abaixo está o script homologado para capturar e ranquear as consultas com maior consumo agregado de
recursos de CPU no servidor:

-- Captura das 5 consultas com maior consumo de CPU acumulado


SELECT TOP 5
[Link] AS [Texto da Consulta],
qs.total_worker_time / 1000 AS [Total CPU (ms)],
qs.execution_count AS [Contagem de Execucoes],
(qs.total_worker_time / qs.execution_count) / 1000 AS [Media CPU (ms)],
qp.query_plan AS [Plano de Execucao]
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) st
CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) qp
ORDER BY qs.total_worker_time DESC;
GO

A análise regular destas DMVs previne gargalos severos de degradação e garante a previsibilidade de
desempenho do cluster de produção.

Página 4

Você também pode gostar