Dez dicas para otimizar o
desempenho do SQL Server
Escrito por Patrick O’Keefe e Richard Douglas
Resumo
A otimização de desempenho no SQL Server pode ser um
desafio. Uma vasta gama de informações está disponível sobre
a forma de abordar os problemas de desempenho em geral. No
entanto, não há muita informação detalhada sobre problemas
específicos e ainda menos informações sobre como aplicar esse
conhecimento específico ao seu próprio ambiente.
Este artigo oferece 10 dicas para otimizar o desempenho do
SQL Server, com SQL Server 2008 e 2012 em mente. Não há
listas definitivas das dicas mais importantes, mas você não
errará começando por aqui.
Como um DBA, você, sem dúvida, tem seu próprio ponto
de vista, assim como suas próprias dicas, truques e scripts
favoritos de otimização. Por que não se juntar à discussão sobre
SQLServerPedia?
Introdução
Considere suas metas de ajuste.
Todos nós queremos obter o valor máximo de nossas
implementações do SQL Server. Aumentar a eficiência de seus
servidores de banco de dados libera recursos do sistema para
outras tarefas, tais como relatórios de negócios ou consultas ad
hoc. Para obter o máximo do investimento em hardware de sua
organização, você precisa garantir que a carga de trabalho do
SQL ou aplicação executada nos servidores do banco de dados
esteja em execução da forma mais rápida e eficiente possível.
Mas o seu ajuste depende de suas metas. Você pode estar se
perguntando: "Será que estou obtendo a melhor eficiência da
minha implantação do SQL Server?". Mas alguém pode estar
se perguntando: "Minha aplicação se ajustará à escala?". Aqui
estão as principais formas de ajustar um sistema:
•  Ajustar para atender às metas do contrato de nível de serviço (SLA)
ou dos indicadores chave de desempenho (KPI)
•  Ajustar para aumentar a eficiência, liberando assim os recursos
para outras finalidades
•  Ajustar para garantir a escalabilidade, ajudando assim a manter
SLAs ou KPIs no futuro
 Lembre-se de que o ajuste é um processo Dica nº 10. A metodologia de criação
contínuo, não uma correção única. de linha de base e referência de
A otimização de desempenho é um desempenho ajuda você a detectar
processo contínuo. Por exemplo, ao os problemas.
ajustar para metas de SLA, será possível ter Visão geral do processo de criação
"concluído". No entanto, se você estiver de linha de base e referência de
ajustando para aumentar a eficiência ou desempenho A Figura 1 ilustra as
garantir a escalabilidade, seu trabalho etapas no processo de criação de linha
nunca será realmente concluído; esse tipo de base. As seções a seguir explicarão
de ajuste deve ser continuado até que o as principais etapas no processo.
desempenho esteja "bom o suficiente".
No futuro, quando o desempenho da
aplicação não for mais bom o suficiente,
Trabalhe para o ciclo de ajuste deverá ser executado
novamente.
aumentar a
"Boa o suficiente" geralmente tem a ver
escalabilidade e com os imperativos de negócios, como
a eficiência de SLAs ou requisitos de taxa de transferência
do sistema. Além desses requisitos, você
todos os servidores deve estar motivado para aumentar a
escalabilidade e a eficiência de todos os
de banco de servidores do banco de dados, mesmo
dados, mesmo se que os requisitos de negócios estejam
sendo cumpridos.
os requisitos de
Sobre este documento
negócios estiverem A otimização do desempenho no SQL
sendo cumpridos. Server é um desafio. Há uma variedade
de informações generalizadas sobre
vários pontos de dados, por exemplo,
contadores de desempenho e objetos de
gerenciamento dinâmico (DMOs), mas há
muito pouca informação sobre o que fazer
com esses dados e como interpretá-los.
Este artigo descreve 10 dicas importantes
que serão úteis nas trincheiras, permitindo
que você transforme alguns desses dados
em informações acionáveis.

Figura 1. O
 processo de criação de
linha de base

2
Antes de começar a fazer alterações, crie
um registro do desempenho atual do
sistema. Ao ajustar e otimizar, a maioria
de nós ficará tentada a ir diretamente
para os ajustes. Alguma vez você já pegou
seu carro no mecânico e pensou que ele
estava funcionando pior do que antes?
Você quer reclamar, mas simplesmente
não tem certeza. Você também pode se
perguntar se a causa do problema que
acha existir agora é algo que o mecânico
fez ou algo que aconteceu depois.
Infelizmente, o desempenho do banco de
dados pode sofrer os mesmos problemas.
Depois de ler este artigo, você estará
cheio de ideias e vai querer implementar
sua estratégia de criação de linha de
base e referência de desempenho
imediatamente. A primeira etapa que
você precisa realizar não é a mais
emocionante, mas certamente é uma das
mais importantes: é hora de estabelecer
como seu ambiente atende aos critérios
que você pretende mudar.
Determine suas metas.
Antes de fazer qualquer coisa em seu
sistema, decida o que você deseja
alcançar. Há aspectos de seu SLA que
precisam ser tratados com respeito ao
desempenho, consumo de recursos ou
capacidade? Você está resolvendo um
problema atual em produção? Houve
queixas com relação ao tempo do
recurso? Estabeleça algumas metas claras.
A maioria de nós tem muitos bancos
de dados e instâncias para cuidar. Para
aumentar o valor de nossos esforços,
precisamos pensar com cuidado no que
é exigido de um determinado sistema de
modo que tenha um bom desempenho
e atenda às expectativas dos usuários.
Se você exagerar na análise e no ajuste,
poderá descobrir que uma quantidade
desproporcional de tempo é gasta
em sistemas de baixa prioridade, em
detrimento dos principais sistemas de
produção. Seja claro sobre exatamente o
que deseja alcançar com seus esforços
de medição e ajuste. Priorize-os e,
idealmente, obtenha adesão e contratos
de um patrocinador de negócios.
3
Estabeleça a norma.
Depois de determinar o que deseja
alcançar, então você precisa decidir
como vai medir o sucesso. Quais são
os contadores de sistema operacional,
contadores do SQL Server, medidas
de recursos e outros pontos de dados
que proporcionarão o discernimento
necessário?
Depois de ter essa lista, você precisará
estabelecer sua linha de base, ou o
desempenho típico de seu sistema,
conforme os critérios escolhidos. Você A referência de
precisa coletar dados suficientes durante
um período de tempo suficientemente desempenho ajuda
longo para dar uma amostra
representativa do desempenho típico
a identificar um
do sistema. Assim que tiver os dados, comportamento
você pode calcular a média dos valores
durante o período para estabelecer sua anormal, porque
primeira linha de base. Depois de fazer
modificações no sistema, você terá
você tem uma boa
uma nova referência de desempenho e indicação do que é
a comparará com a original para poder
medir objetivamente o efeito de suas um comportamento
alterações. normal.
Não monitore apenas os valores
médios; acompanhe também o desvio
da norma. No entanto, é importante ter
cuidado com as médias. No mínimo,
calcule o desvio padrão de cada
contador para ter uma indicação da
variação ao longo do tempo. Considere
um alpinista que soube que o diâmetro
médio da corda é de 1 cm. O alpinista
salta com confiança para o lado.
Ele balança várias centenas de metros
sobre as rochas afiadas e sorri, satisfeito.
Em seguida, ele descobre que a seção
mais grossa da corda é de 2 cm e a mais
fina é de 0,1 cm. Ops!
Se você não estiver familiarizado com
o desvio padrão, consulte um livro de
estatísticas para iniciantes. Você não
precisa saber tudo, mas ajuda saber o
básico.
A mensagem principal aqui não é apenas
acompanhar as médias, mas também
acompanhar o desvio da norma (meio).
Decida o que essa norma deve ser (isso
é frequentemente encontrado no SLA).
 Sua missão não é obter o máximo
desempenho possível, e sim conseguir
o melhor ajuste possível para suas
metas de desempenho e, em seguida,
limitar o desvio dessas metas o máximo
possível. Tudo mais representa tempo e
esforço desperdiçados e também pode
apontar para uma subutilização dos
recursos de infraestrutura.
Qual é o volume de dados necessário
para uma linha de base? A quantidade
de dados necessários para estabelecer
uma linha de base depende de como
Sua missão não é a carga varia ao longo do tempo.
obter o máximo Converse com os administradores
de sistema, usuários finais e
desempenho administradores de aplicações. Eles
geralmente têm uma boa noção de
possível; é conseguir quais são os padrões de uso. Você deve
o melhor ajuste reunir dados suficientes para cobrir
períodos fora de pico, médios e de pico.
possível para É importante medir a quantidade que
varia de carga e com que frequência.
suas metas de Os sistemas com padrões previsíveis
desempenho e, em exigirão menos dados. Quanto maior a
variação, menor o intervalo de medição
seguida, limitar o e maior o tempo que você precisará
para medir e desenvolver uma linha de
desvio dessas metas base confiável. Para ir um pouco mais
o máximo possível. além em nossa analogia do alpinista,
quanto maior o comprimento de corda
que você examinar, melhor a chance
de detectar as variações. A criticidade
do sistema e o impacto do seu fracasso
também afetarão a quantidade de
análise a que ele deve ser submetido e a
confiabilidade que a amostra deve ter.
Armazenamento dos dados
Quanto mais parâmetros você
monitorar e quanto menor a frequência,
maior o conjunto de dados que você
vai coletar. Pode parecer óbvio, mas
você precisa considerar a capacidade
que será necessária para armazenar
seus dados de medição. Quando
você tiver alguns dados, será bastante
simples extrapolar a medida em que
este repositório vai crescer ao longo do
tempo. Se você monitorar durante um
período prolongado, considere agregar
dados históricos em intervalos para
evitar que o repositório aumente muito.
Por motivos de desempenho, seu
repositório de medição não deve residir
4
no mesmo lugar que o banco de dados
sendo monitorado.
Limite o número de alterações feitas ao
mesmo tempo.
Tente limitar o número de alterações
feitas entre cada referência de
desempenho. Construa suas
modificações para testar uma hipótese
específica. Isso permitirá que você inclua
ou exclua de forma meticulosa cada
candidato a melhoria. Ao aprimorar uma
solução, você entenderá exatamente
por que está vendo a mudança no
comportamento, e isso muitas vezes
revela uma série de opções adicionais de
possível melhoria.
Análise dos dados
Depois de fazer alterações em seu
sistema, você vai querer determinar
se elas tiveram o efeito desejado. Para
conseguir isso, repita as medidas tomadas
para a linha de base original por meio
de uma escala de tempo similarmente
representativa. Você pode então
comparar as duas linhas de base para:
Determinar se suas alterações causaram
•  
o efeito desejado — Quando você ajustar
uma configuração, otimizar um índice
ou uma mudança no código SQL, a linha
de base permitirá dizer se essa mudança
teve o efeito desejado. Se você receber
uma reclamação sobre um desempenho
mais lento, poderá dizer com certeza se
a instrução é precisa sob a perspectiva do
banco de dados.
O erro mais frequente que a maioria dos
DBAs juniores comete é tirar conclusões
precipitadas. Muitas vezes, você verá alguém
pular de alegria ao observar um aumento
imediato no desempenho depois de fazer
uma ou mais alterações. Eles implantam na
produção e se apressam em enviar e-mails
informando que o problema foi resolvido. Mas
as comemorações poderão ter curta duração
quando os mesmos problemas ressurgem
algum tempo depois ou algum efeito colateral
desconhecido provocar outro problema.
Muitas vezes, isso pode resultar em um estado
que é menos desejável do que o original.
Quando achar ter encontrado a resposta para
um problema, teste-a e faça uma referência de
desempenho dos resultados na linha de base.
Esta é a única maneira confiável de saber com
certeza que você progrediu.
•  Determinar se uma alteração apresentou
algum efeito colateral inesperado —
Uma linha de base também permite ver
objetivamente se uma mudança afetou um
contador ou medida que você não esperava
ser afetado.
•  Antecipar os problemas antes que eles
aconteçam — Ao usar uma linha de base, você
pode estabelecer normas de desempenho
precisas em condições de carga típicas. Isto
lhe permitirá prever se e quando você terá
problemas no futuro, com base em como
o consumo de recursos está tendendo hoje
ou nas cargas de trabalho projetadas para
cenários futuros. Por exemplo, você executa
o planejamento de capacidade: ao extrapolar
o consumo normal de recursos atuais por
usuário conectado, será possível prever quando
seus sistemas terão gargalos de conexão do
usuário.
•  Solucionar problemas de forma mais eficaz —
Já passou vários dias e noites combatendo
um problema de desempenho com seu banco
de dados só para descobrir que na verdade
não tinha nada a ver com o banco de dados
em si? Estabelecer uma linha de base torna
muito mais fácil eliminar a instância de banco
de dados e apontar o culpado. Por exemplo,
suponha que o consumo de memória, de
repente, disparou. Você percebe o número
de conexões aumentando drasticamente e
bem acima de sua linha de base. Uma ligação
rápida para o administrador da aplicação
confirma que um novo módulo foi implantado
na loja virtual. Não demora muito para
provar que o novo desenvolvedor júnior está
escrevendo um código que não libera as
conexões de banco de dados como deveria.
Aposto que você pode imaginar muitas outras
situações como esta.
Excluir as coisas que NÃO são responsáveis ​​
por um problema pode poupar uma grande
quantidade de tempo eliminando a confusão
e proporcionando um foco sobre exatamente
o que está causando o problema. Existem
muitos exemplos em que podemos comparar
contadores do sistema aos contadores do
SQL Server para incluir ou excluir rapidamente
o banco de dados de um problema. Depois
que os suspeitos de costume forem
descartados, você poderá começar a busca
por desvios significativos na linha de base,
coletar indicadores relacionados e analisar a
causa raiz.
5
Repita o processo de criação de linha de
base quantas vezes forem necessárias.
O bom ajuste é um processo iterativo
e científico. As dicas apresentadas
neste documento fornecem um bom
ponto de partida, mas elas são apenas
isso: um ponto de partida. O ajuste de
desempenho é altamente personalizado
e regido pelo design, composição e uso
de cada sistema individual.
A metodologia de criação de linha de
base e referência de desempenho é o
elemento central do bom e confiável A quantidade de
ajuste de desempenho. Ela fornece o
mapa, uma referência e os pontos de dados necessários
interesse necessários para descobrirmos
onde precisamos ir e como chegar
para estabelecer
lá, para nos ajudar a garantir que não uma linha de base
nos perderemos no caminho. Uma
abordagem estruturada nos permite criar depende de como a
um desempenho confiável e consistente
em todo nosso portfólio do banco de
carga varia ao longo
dados. do tempo.
Dica nº 9. Os contadores de
desempenho fornecem informações
rápidas e úteis sobre as operações
atualmente em execução.
Motivos para monitorar os contadores
de desempenho
Uma pergunta muito comum relacionada
à otimização de desempenho do
SQL Server é: "Quais contadores
eu devo monitorar?" Em termos de
gerenciamento do SQL Server, há dois
grandes motivos para monitorar os
contadores de desempenho:
•  Aumento da eficiência operacional
•  Prevenção de gargalos
Embora se sobreponham, esses dois
motivos permitem que você escolha
facilmente uma série de pontos de dados
para monitorar.
Monitorar contadores de desempenho
para aumentar a eficiência operacional
O monitoramento operacional verifica
o uso geral de recursos. Ele ajuda a
responder a perguntas, tais como:
•  O servidor está prestes a ficar sem
recursos, como CPU, espaço em disco ou
memória?
•  Os arquivos de dados podem aumentar?
•  Os arquivos de dados de tamanho fixo têm
espaço livre para dados?
 Você também pode usar os dados para Para responder às três perguntas feitas
fins de tendência. Um bom exemplo seria acima, você deve analisar os seguintes
coletar os tamanhos de todos os arquivos contadores:
de dados para direcionar suas taxas de
crescimento e prever futuras necessidades
de recursos.

Medidor Permite a você

Processor\%Processor Time Monitorar o consumo da CPU no servidor
LogicalDisk\Free MB Monitorar o espaço livre no(s) disco(s)
MSSQL$Instance:Databases\DataFile(s) Size (KB) Direcionar o crescimento ao longo do tempo
Memory\Pages/sec Verificar a paginação, que é uma boa indicação de
que os recursos de memória podem ser curtos
Limite o número Memory\Available MBytes Ver a quantidade de memória física disponível para
uso do sistema
de alterações
feitas entre cada Monitorar os contadores de desempenho •  Os principais subsistemas do SQL
para evitar gargalos Server, como o cache de buffer e
referência de O monitoramento de gargalos se cache de planos estão íntegros?

desempenho, para concentra mais em questões relacionadas

ao desempenho. Os dados coletados
•  Existe contenção no banco de dados?

que possa avaliar ajudam a responder a perguntas, tais Para responder a essas perguntas,
como: analise os seguintes contadores:
meticulosamente •  Existe um gargalo da CPU?
os efeitos de cada •  Existe um gargalo de E/S?

mudança. Medidor Permite a você

Processor\%Processor Time
Alta porcentagem de espera de sinal
Disco físico\média Tamanho da fila do disco
MSSQL$Instance:Buffer Manager\Page Life
Expectativa
MSSQL$Instance:Plan Cache\Cache Hit Ratio
MSSQL$Instance:General Statistics\Processes
Blocos
Monitorar o consumo da CPU permite que você
verifique se há um gargalo no servidor (indicado pelo
alto uso sustentado).
Espera de sinal é o tempo que um trabalhador gasta
aguardando o tempo da CPU após ter acabado de
esperar algo mais (como um bloqueio, uma trava ou
outro sinal de espera).
O tempo gasto esperando a CPU é indicativo
de um gargalo da CPU.
A espera de sinal pode ser encontrada executando
DBCC SQLPERF(waitstats) no SQL Server 2000
ou consultando sys.dm_os_wait_stats no
SQL Server 2005.
Verifique se há gargalos de disco: se o valor for
superior a 2, então será provável que exista um
gargalo de disco.
Expectativa de vida da página é o número de
segundos que uma página permanece no cache do
buffer. Um número baixo indica que as páginas estão
sendo despejadas sem gastar muito tempo no cache,
o que reduz a eficácia do cache.
Uma baixa taxa de acertos do cache de planos
significa que os planos não estão sendo reutilizados.
Blocos longos indicam contenção de recursos.

6
Dica nº 8. Alterar as configurações
do servidor pode proporcionar um
ambiente mais estável.
Alterar as configurações dentro de um
produto para torná-lo mais estável
pode parecer contraintuitivo, mas,
neste caso, realmente funciona. Como
um DBA, seu trabalho será garantir
um nível consistente de desempenho
para seus usuários quando eles
solicitam dados de suas aplicações.
Sem alterar as configurações descritas
no restante deste documento, você
pode experimentar cenários que
podem degradar o desempenho
de seus usuários, sem aviso prévio.
Essas opções podem ser facilmente
encontradas em sys. configurations,
que lista as configurações no nível do
servidor, disponíveis juntamente com
informações adicionais. O atributo
Is_Dynamic em sys.configurations
mostra se a instância do SQL Server
precisará ser reiniciada após uma
alteração da configuração. Para
fazer a alteração, você chamaria
o procedimento sp_configure
armazenado com os parâmetros
relevantes.
As configurações de memória Mín. e
Máx. podem garantir um determinado
nível de desempenho.
Suponhamos que temos um cluster
Ativo/Ativo (ou um único host com
várias instâncias). Podemos fazer
algumas alterações de configuração
que podem garantir que vamos cumprir
nossos SLAs, no caso de um failover,
em que ambas as instâncias residem na
mesma caixa física.
Neste cenário, fazemos alterações na
configuração de memória Mín. e Máx.
para garantir que o host físico tenha
memória suficiente para lidar com
cada instância sem precisar tentar
constantemente cortar de forma
agressiva o conjunto de trabalho do
outro. Uma alteração semelhante na
configuração pode ser feita para utilizar
alguns processadores, a fim de garantir
um determinado nível de desempenho.
É importante observar que configurar
7
a memória máxima não é apenas
adequado para instâncias em um
cluster, mas também aquelas instâncias
que compartilham recursos com
qualquer outra aplicação. Se o uso de
memória do SQL Server for muito alto,
o sistema operacional poderá cortar
agressivamente a quantidade de memória
que pode utilizar, a fim de permitir que
ele próprio ou outra sala de aplicações
funcione.
•  SQL Server 2008 — No SQL Server 2008
R2 e anterior, a configuração de memória
Mín. e Máx. restringe apenas a quantidade
de memória que o pool de buffers usa (mais
Sage aconselha
especificamente, apenas alocações de sobre como
página única de 8 KB). Isso significa que se
você executasse processos fora do pool de
solucionar
buffers (como procedimentos armazenados
estendidos, CLR ou outros componentes,
problemas em
como Integration Services, Reporting apenas três
Services ou Analysis Services), você
precisaria reduzir ainda mais esse valor.
palavras: "Eliminar
SQL Server 2012 — O SQL Server 2012
•  
muda um pouco as coisas quando há um
ou incriminar".
gerenciador de memória central. Este
gerenciador de memória agora incorpora
alocações de várias páginas, como grandes
páginas de dados e planos em cache que
são maiores do que 8 KB. Este espaço de
memória agora também inclui algumas
funcionalidades de CLR.
Duas opções de servidor podem ajudar o
desempenho indiretamente.
Não há opções que auxiliam diretamente
o desempenho, mas há duas opções que
podem ajudar de forma indireta.
•  Padrão de compactação de back-up —
Esta opção define que os backups sejam
compactados por padrão. Embora isto
possa produzir ciclos extras de CPU
durante a compactação, em geral, menos
ciclos de CPU são usados ​​em comparação
a um back-up não compactado, pois
menos dados são gravados no disco.
Dependendo da sua arquitetura de E/S, a
configuração dessa opção também pode
reduzir a contenção de E/S.
•  A segunda opção pode ou não ser
divulgada em uma dica futura no cache de
planos. Você vai ter que esperar e ver se
chegou à nossa lista de top 10.
 Dica nº 7. Encontre consultas de
invasores no cache do plano.
Depois de identificar um gargalo,
você precisará encontrar a carga de
trabalho que está causando o gargalo.
Isso é muito mais fácil de fazer desde a
introdução de objetos de gerenciamento
dinâmico (DMOs) no SQL Server 2005.
Usuários do SQL Server 2000 e anterior
terão de se contentar com o uso do
Profiler ou rastreamento (mais sobre isso
na Dica nº 6).
Diagnosticar um gargalo de
CPU No SQL Server, se você
identificou um gargalo de CPU, a
primeira coisa que deverá fazer é
obter os principais consumidores
de CPU no servidor. Esta é uma
consulta muito simples em sys.
dm_exec_query_stats:

Monitorar os SELECT TOP 50

qs.total_worker_time / execution_count AS avg_worker_time,
contadores de substring (st.text, (qs.statement_start_offset / 2) + 1,
(  ( CASE qs.statement_end_offset WHEN -1
desempenho pode THEN datalength (st.text)

ajudar a aumentar

ELSE qs.statement_end_offset END
- qs.statement_start_offset)/ 2)+ 1)
a eficiência AS statement_text,
*
operacional e evitar FROM sys.dm_exec_query_stats AS qs

gargalos. CROSS APPLY sys.dm_exec_sql_text (qs.sql_handle) AS st

ORDER BY
avg_worker_time DESC

A parte realmente útil dessa consulta é Diagnosticar um gargalo de E/S A

sua habilidade de usar aplicação cruzada história é semelhante para um gargalo
e sys.dm_exec_sql_text para obter a de E/S:
instrução SQL para analisá-la.

SELECT TOP 50
     (total_logical_reads + total_logical_writes) AS total_logical_io,
     (total_logical_reads / execution_count) AS avg_logical_reads,
     (total_logical_writes / execution_count) AS avg_logical_writes,
     (total_physical_reads / execution_count) AS avg_phys_reads,
substring (st.text,
(qs.statement_start_offset / 2) + 1,
     ((CASE qs.statement_end_offset WHEN -1
       THEN datalength (st.text)
      ELSE qs.statement_end_offset END
      - qs.statement_start_offset)/ 2)+ 1)
     AS statement_text,
 *
FROM sys.dm_exec_query_stats AS qs
    CROSS APPLY sys.dm_exec_sql_text (qs.sql_handle) AS st
ORDER BY total_logical_io DESC

8
Dica nº 6. O SQL Profiler é seu amigo.
Entender o SQL Server Profiler e os
eventos estendidos
O SQL Server Profiler é uma ferramenta
nativa fornecida com o SQL Server.
Ele permite que você crie um arquivo
de rastreamento para capturar eventos
que ocorrem no SQL Server. Esses
rastreamentos podem ser inestimáveis
na prestação de informações sobre
sua carga de trabalho e consultas com
baixo desempenho. Este white paper
não discutirá os detalhes sobre como
usar a ferramenta do Profiler. Para obter
informações sobre como usar o SQL
Server Profiler, confira o tutorial em
vídeo no SQLServerPedia.
Embora seja verdade que o SQL Server
Profiler foi marcado como preterido no
SQL Server 2012 em favor de eventos
estendidos, deve-se observar que isso
é apenas para o mecanismo do banco
de dados e não para o SQL Server
Analysis Services. O Profiler ainda pode
fornecer grandes informações sobre
o funcionamento de aplicações em
tempo real para muitos ambientes do
SQL Server.
O uso de eventos estendidos está fora
do escopo deste white paper. Para obter
uma descrição detalhada dos eventos
estendidos, consulte o white paper
"Como usar os eventos estendidos
e notificações do SQL Server para
solucionar problemas de desempenho
de forma proativa" (em inglês). Basta
dizer que os eventos estendidos foram
introduzidos no SQL Server 2008 e
atualizados no SQL Server 2012 para
incluir mais eventos e uma interface de
usuário muito aguardada.
Observe que a execução do Profiler
requer a permissão ALTER TRACE.
9
Como usar o SQL Profiler
Veja como construir o processo
de coleta de dados no Monitor de
desempenho (Perfmon) e correlacionar
a informação sobre o uso de recursos
com dados nos eventos que estão sendo
disparados dentro do SQL Server:
1. Abra o Perfmon.
2. Se você não tiver um coletor de dados
definido já configurado, crie um
agora usando a opção avançada e os
contadores da Dica 9 como um guia.
Não inicie o coletor de dados definido
ainda.
O monitoramento
3. Abra o Profiler.
4. Crie um novo rastreamento especificando operacional
os detalhes sobre a instância, os eventos
e as colunas que você deseja monitorar,
verifica o uso geral
bem como o destino. de recursos. O
5. Inicie o rastreamento.
6. Retorne para o Perfmon para iniciar o
monitoramento
coletor de dados definido. de gargalos se
7. Deixe ambas as sessões executando
até que os dados necessários sejam
concentra mais
capturados. em questões
8. Pare o rastreamento do Profiler. Salve o
rastreamento e, em seguida, feche-o. relacionadas ao
9. Volte para o Perfmon e pare a coleta de desempenho.
dados definida.
10. Abra o arquivo de rastreamento salvo
recentemente no Profiler.
11. Clique em File (Arquivo) e, em seguida,
Import Performance Data (Importar
dados de desempenho).
12. Navegue até o arquivo de dados
da Coleta de dados e selecione os
contadores de desempenho de interesse.
Agora, você será capaz de ver os
contadores de desempenho em
conjunto com o arquivo de rastreamento
do Profiler (consulte a Figura 2), o que
permitirá uma resolução de gargalos
muito mais rápida.
Dica extra: as etapas acima usam
a interface do cliente. Para poupar
recursos, um rastreamento no lado do
servidor seria mais eficiente. Consulte
os livros on-line para obter informações
sobre como iniciar e parar rastreamentos
no lado do servidor.
 O atributo Is_
Dynamic em Sys.
Configurations Figura 2. Uma visão correlacionada de contadores de desempenho em conjunto com o
mostra se a arquivo de rastreamento do Profiler
instância do SQL Dica nº 5. Configure SANs para
Server precisará desempenho do SQL Server.
As redes de área de armazenamento (SANs)
ser reiniciada após são fantásticas. Elas oferecem a capacidade
de provisionar e gerenciar o armazenamento
uma alteração da de uma forma simples. SANs podem ser
configuração. configurados para um desempenho rápido
a partir de uma perspectiva do SQL Server,
mas muitas vezes não são. As organizações
geralmente implementam SANs para
consolidação de armazenamento e facilidade
de gerenciamento, não para desempenho.
Para piorar a situação, geralmente você não
tem controle direto sobre a forma como
o provisionamento é feito em uma SAN.
Assim, você frequentemente verá que a SAN
foi configurada para um volume lógico em
que você deve colocar todos os arquivos de
dados.
Melhores práticas para configurar SANs para
desempenho de E/S
Ter todos os arquivos em um único volume
geralmente não é uma boa ideia se você
quiser o melhor desempenho de E/S. Como
melhores práticas, você vai querer:
• Colocar os arquivos de registro em seu
próprio volume, separados dos arquivos
de dados. Os arquivos de registro são
quase exclusivamente gravados como
sequência e não leitura (as exceções incluem
Espelhamento de banco de dados e Grupos
de disponibilidade Always On). Você deve
sempre configurar para rápido desempenho de
gravação.
• Colocar tempdb em seu próprio volume.
Tempdb é usado para uma série de propósitos
pelo SQL Server internamente, então, tê-lo em
10
seu próprio subsistema de E/S é útil. Para ajustar
ainda mais o desempenho, primeiro você
precisa de algumas estatísticas.
• Considere a criação de vários arquivos de
dados e grupos de arquivos em VLDBs para
se beneficiar de operações de E/S paralelas.
• Coloque os backups em suas próprias
unidades para fins de redundância, bem
como reduzir a contenção de E/S com outros
volumes durante os períodos de manutenção.
Coleta de dados
Há, é claro, os contadores de disco do
Windows, que dão uma ideia do que o
Windows acha que está acontecendo. (Não
se esqueça de ajustar os números brutos com
base na configuração RAID.) Fornecedores de
SAN costumam oferecer seus próprios dados
de desempenho.
O SQL Server também fornece
informações de E/S no nível do arquivo:
• Versões anteriores ao SQL 2005 — Use a
função fn_virtualfilestats.
• Versões posteriores — Use a função de
gerenciamento dinâmico sys.dm_io_virtual_
file_stats.
Ao usar essa função no seguinte código,
você pode:
• Derivar taxas de E/S para leituras e gravações
• Obter a taxa de transferência de E/S
• Obter uma média de tempo por E/S
• Analisar os tempos de espera de E/S
 SELECT db_name (a.database_id) AS [DatabaseName],
     b.name AS [FileName], a.File_ID AS [FileID],
     CASE WHEN a.file_id = 2 THEN ‘Log’ ELSE ‘Data’ END AS [FileType],
    a.Num_of_Reads AS [NumReads],
    a.num_of_bytes_read AS [NumBytesRead],
    a.io_stall_read_ms AS [IOStallReadsMS],
    a.num_of_writes AS [NumWrites],
    a.num_of_bytes_written AS [NumBytesWritten],
    a.io_stall_write_ms AS [IOStallWritesMS],
    a.io_stall [TotalIOStallMS],
     DATEADD (ms, -a.sample_ms, GETDATE ()) [LastReset],
     ( (a.size_on_disk_bytes / 1024) / 1024.0) AS [SizeOnDiskMB],
     UPPER (LEFT (b.physical_name, 2)) AS [DiskLocation] Configurar backups
  FROM sys.dm_io_virtual_file_stats (NULL, NULL) a para que sejam
   JOIN sys.master_files b
     ON a.file_id = b.file_id AND a.database_id = b.database_id compactados por
ORDER BY a.io_stall DESC; padrão reduz a
contenção de E/S.
Análise dos dados Dicas para ajustar seu hardware se os
Preste atenção especial ao valor arquivos de banco de dados estiverem
"LastReset" na consulta; ele mostra a corretamente colocados e todos os
última vez que o serviço do SQL Server pontos de acesso de objetos tiverem
foi iniciado. Os dados de objetos de sido identificados e separados em
gerenciamento dinâmico não são diferentes volumes, então, estará na
persistentes, então, quaisquer dados hora de dar uma olhada no hardware.
sendo usados para fins de ajuste devem
ser validados em relação ao tempo de Ajustar o hardware é um tema
execução do serviço, caso contrário, especializado fora do escopo deste
podem ser feitas falsas suposições. white paper. Porém, há algumas
melhores práticas e dicas que eu posso
Ao usar esses números, você poderá compartilhar com você para tornar isso
rapidamente restringir quais arquivos são mais fácil:
responsáveis ​​pelo consumo da largura de •  Não use o tamanho da unidade de
banda de E/S e fazer perguntas como: alocação padrão ao criar volumes para
•  Este E/S é necessário? Está faltando um usar com o SQL Server. O SQL Server usa
índice? extensões de 64 KB, então, esse valor
•  Será que uma tabela ou índice em um deve ser o mínimo.
arquivo é responsável? Posso colocar esse •  Veja se suas partições estão alinhadas
índice ou tabela em outro arquivo em outro corretamente. Jimmy May escreveu
volume? um white paper fantástico sobre esse
assunto. Partições desalinhadas podem
reduzir o desempenho em até 30%.
•  Crie uma referência de desempenho para
a E/S do seu sistema usando uma ferramenta
como SQLIO. Você pode assistir a um
tutorial sobre essa ferramenta.

Figura 3. Informações de E/S em nível do arquivo do SQL Server

11
 Dica nº 4. Cursores e outro T-SQL
ruim frequentemente voltam para
assombrar as aplicações.
Um exemplo de código ruim
Em um trabalho anterior, descobri o que
deve ser o pior código que já vi na minha
carreira. O sistema foi substituído há muito
tempo, mas aqui está um resumo do
processo pelo qual a função passou:
1. Aceite o valor de parâmetro a ser removido.
2. Aceite a expressão de parâmetro a ser
removida.
3. Descubra o tamanho da expressão.
O SQL Profiler 4. Carregue a expressão em uma variável.
5. Execute um ciclo com cada caractere na
ainda pode variável e verifique se esse caractere combina
fornecer grandes com um dos valores a ser removido. Se
combinar, atualize a variável para removê-la.
informações sobre 6. Siga para o próximo caractere até que a
expressão seja completamente verificada.
o funcionamento
Se você estiver horrorizado, então, somos
de aplicações em dois. É claro que estou explicando a
tempo real para tentativa de alguém de escrever sua própria
instrução "REPLACE" do T-SQL!
muitos ambientes
A pior parte é que essa função foi utilizada
do SQL Server. para atualizar os endereços como parte
de uma rotina de endereçamento e seria
chamada dezenas de milhares de vezes por
dia.
Executar um rastreamento do Profiler no
lado do servidor permite visualizar a carga
de trabalho do servidor e escolher partes de
código executadas com frequência (que é
como essa "joia" foi encontrada).
Figura 4. Exemplo de um grande plano de consulta
12
Ajuste de consulta usando planos de
consulta Um T-SQL ruim também pode
parecer com consultas ineficientes que
não usam índices, principalmente porque o
índice está incorreto ou ausente. É de vital
importância ter um bom entendimento
sobre como ajustar consultas usando
planos de consulta.
Uma discussão detalhada sobre ajuste de
consulta usando planos de consulta está
fora do escopo deste white paper. No
entanto, a maneira mais simples de iniciar
este processo é transformando operações
SCAN em SEEKs. Os SCANs leem cada linha
na tabela ou índice, então, para tabelas
grandes, eles são caros em termos de E/S.
Um SEEK, por outro lado, usará um índice
para ir direto até a linha necessária, o que,
obviamente, exige um índice. Se você
encontrar SCANs em sua carga de trabalho,
os índices poderão estar ausentes.
Existe uma série de bons livros sobre
esse tema, inclusive:
•  "Professional SQL Server Execution Plan
Tuning" (Ajuste do plano de execução do
Professional SQL Server) por Grant Fritchey
•  "Professional SQL Server 2012 Internals &
Troubleshooting" (Solução de problemas e
operações internas do Professional SQL Server
2012) por Christian Bolton, Rob Farley, Glenn
Berry, Justin Langford, Gavin Payne, Amit
Banerjee, Michael Anderson, James Boother e
Steven Wort
•  "T-SQL Fundamentals for Microsoft SQL Server
2012 and SQL Azure" (Princípios básicos do
T-SQL para Microsoft SQL Server 2012 e SQL
Azure) por Itzik Ben-Gan
Dica nº 3. Aumente a reutilização do plano Avaliar se você está recebendo um bom
para obter melhor caching do SQL Server. plano de reutilização
Por que a reutilização de planos de consulta é
importante
Antes de executar uma instrução SQL, o SQL
Server primeiro cria um plano de consulta.
Isso define o método que o SQL Server usará
para levar a instrução lógica da consulta e
implementá-la como uma ação física nos
dados.
Criar um plano de consulta pode exigir CPU
significativa. Assim, o SQL Server será executado sendo compilado, e não há nenhuma
de forma mais eficiente se puder reutilizar
planos de consulta em vez de criar um novo
cada vez que uma instrução SQL for executada.
(Batch Requests/sec – SQL Compilations/sec) / Batch Requests/sec
Abordar uma reutilização de plano ruim
Não é fácil definir a carga de trabalho
exata responsável pela reutilização ruim
do plano, pois o problema geralmente
está no código da aplicação cliente que
envia as consultas. Portanto, você pode
precisar analisar o código da aplicação
cliente que está enviando as consultas.
Para encontrar o código incorporado
dentro de uma aplicação cliente,
você terá que usar os eventos
estendidos ou o Profiler. Ao adicionar
o evento SQL:StmtRecompile em um
rastreamento, você será capaz de ver
quando um evento de recompilação
ocorre. (Há também um evento chamado
SP:Recompile, que é incluído para
compatibilidade com versões anteriores,
pois a ocorrência de recompilação foi
alterada no nível de procedimento para o
nível de instrução no SQL Server 2005.)
13
Há alguns contadores de desempenho
disponíveis no objeto de desempenho
de estatísticas SQL que lhe dirão se você
está tendo uma boa reutilização do
plano. Esta fórmula informa a relação de
lotes submetidos para compilações:
Você quer que esse número seja o
mais baixo possível. Uma relação 1:1
significa que cada lote enviado está
reutilização de plano.
SANs podem ser
configurados para
um desempenho
rápido a partir de
uma perspectiva
do SQL Server,
Um problema comum é que o mas muitas vezes
código não está usando instruções
parametrizadas preparadas. Usar
não são.
consultas parametrizadas não só melhora
a reutilização do plano e sobrecarga
de compilação, mas também reduz
o risco de ataque de injeção de SQL
envolvido ao analisar parâmetros por
meio da concatenação de cadeias.
A Figura 5 mostra dois exemplos de
código. Embora sejam inventados, eles
ilustram a diferença entre construir uma
instrução por meio de concatenação de
cadeia e usar instruções preparadas com
parâmetros.

As informações
de E/S no nível do
arquivo do SQL
Server podem ajudar
você a identificar
quais arquivos estão
consumindo largura Figura 5. Comparação do código que constrói uma instrução por meio de
concatenação de cadeia e código que usa instruções preparadas com parâmetros
de banda de E/S.
O SQL Server não pode reutilizar o plano
do exemplo "ruim" na Figura 5. Se um
parâmetro for um tipo de cadeia, esta
função poderá ser usada para montar
um ataque de injeção de SQL. O "bom"
exemplo não é suscetível a um ataque de
injeção de SQL porque um parâmetro é
usado e o SQL Server é capaz de reutilizar
o plano.
A definição de configuração ausente
na Dica nº 8
Aqueles de vocês com uma boa memória
vão lembrar que na Dica nº 8 (em
que falamos sobre as mudanças de
configuração) havia mais um conselho
que não foi falado. O SQL Server 2008
introduziu uma definição de configuração
chamada "Otimizar para cargas de trabalho
ad hoc". Essa configuração solicitará que
o SQL Server armazene um plano de
stub em vez de um plano completo no
cache de planos. Isto é especialmente
útil para ambientes que usam o código
T-SQL construído dinamicamente ou Linq,
que pode resultar na não reutilização do
código.
14
Ruim
Bom
A memória alocada para o cache
de planos reside no pool de buffer.
Portanto, um cache de planos
sobrecarregado reduz a quantidade
de páginas de dados que podem ser
armazenadas no cache de buffer, assim,
haverá mais viagens de ida e volta para
buscar dados no subsistema de E/S, que
podem ser muito caras.
Dica nº 2. Aprenda a ler o cache de
buffer do SQL Server e minimizar a
sobrecarga do cache.
Por que o cache de buffer é importante
Como mencionado no segue bastante
elegante acima, o cache de buffer
é uma grande área de memória
usada pelo SQL Server para reduzir
a necessidade de realizar E/S físico.
Nenhuma execução de consulta do
SQL Server lê os dados diretamente
de um disco; as páginas do banco de
dados são lidas no cache de buffer. Se a
página procurada não estiver no cache
de buffer, uma solicitação de E/S físico
ficará na fila. Em seguida, a consulta
aguarda e a página é obtida no disco.
As alterações dos dados em uma
página de uma operação DELETE ou
UPDATE também são feitas às páginas
no cache de buffer. Estas alterações são
depois transmitidas ao disco. Todo esse
mecanismo permite que o SQL Server
otimize o E/S físico de várias maneiras:
•  Várias páginas podem ser lidas e escritas em
uma operação de E/S.
•  A leitura antecipada pode ser implementada.
O SQL Server pode notar que para
determinados tipos de operações, pode ser
útil ler páginas em sequência, supondo que
logo depois de ler a página solicitada, você
vai querer ler a página adjacente.
Nota: a fragmentação de índice prejudicará de milhares e não centenas. Essa diferença
a capacidade do SQL Server de executar a
otimização de leitura antecipada.
Avaliação da integridade do cache de
buffer
Há duas indicações da integridade do
cache de buffer:
•  Taxa de acertos do cache
MSSQL$Instance:Buffer Manager\Buffer —
Esta é a relação de páginas encontradas no
cache e páginas não encontradas no cache
(as páginas que devem ser lidas fora do disco). despejadas para dar espaço a páginas que
Idealmente, você quer que esse número seja
o mais alto possível. É possível ter uma alta
taxa de acertos, mas ainda experimentar a
sobrecarga do cache.
•  MSSQL$Instance:Buffer Manager\Expectativa cache é geralmente uma indicação de que
de vida da página — Esta é a quantidade
de tempo que o SQL Server está mantendo
as páginas no cache de buffer antes de
serem despejadas. A Microsoft diz que uma
expectativa de vida da página superior a
cinco minutos é satisfatória. Se a expectativa
de vida ficar abaixo disso, poderá ser um
indicador de pressão de memória (memória
insuficiente) ou sobrecarga do cache.
Eu gostaria de concluir esta seção com
uma analogia; muitas pessoas argumentam
que a inovação de travas antibloqueio e
de outras tecnologias assistidas significa
que as distâncias de travamento devem
ser reduzidas, e também que os limites
de velocidade podem ser aumentados de
acordo com essa nova tecnologia. O valor
de aviso de 300 segundos (cinco minutos)
para Expectativa de vida da página incorre
em um debate semelhante na comunidade
do SQL Server: alguns acreditam que esta é
uma regra dura e rápida, enquanto outros
acreditam que o aumento da capacidade
de memória na maioria dos servidores nos Se os arquivos
dias de hoje significa que o valor deve ser
de banco de
de opinião destaca a importância das linhas
de base e por que é tão importante ter uma dados estiverem
compreensão detalhada do que os níveis
de alerta de cada contador de desempenho
corretamente
deve ser no seu ambiente, colocados e todos
Sobrecarga do cache os pontos de acesso
Durante uma grande verificação de tabela
ou índice, cada página na verificação deve de objetos tiverem
passar pelo cache de buffer, o que significa
que páginas possivelmente úteis serão
sido identificados
provavelmente não serão lidas mais de
e separados em
uma vez. Isto gera alto índice de E/S já diferentes volumes,
que as páginas despejadas devem ser lidas
no disco novamente. Esta sobrecarga de então é hora de
grandes tabelas ou índices estão sendo
dar uma olhada no
verificados. hardware.
Para saber quais tabelas e índices estão
ocupando mais espaço no cache de buffer,
você pode examinar o DMV sys.dm_os_
buffer_descriptors (disponível a partir do
SQL Server 2005). A consulta de exemplo a
seguir ilustra como acessar a lista

SELECT o.name, i.name, bd.*

 FROM sys.dm_os_buffer_descriptors bd
   INNER JOIN sys.allocation_units a
     ON bd.allocation_unit_id = a.allocation_unit_id
   INNER JOIN
   sys.partitions p
     ON (a.container_id = p.hobt_id AND a.type IN (1, 3))
       OR (a.container_id = p.partition_id AND a.type = 2)
   INNER JOIN sys.objects o ON p.object_id = o.object_id
   INNER JOIN sys.indexes i
     ON p.object_id = i.object_id AND p.index_id = i.index_id

15
 de tabelas ou índices que estão
consumindo espaço no cache de buffer
do SQL Server:
Você também pode usar os DMVs de
índice para descobrir quais tabelas ou
índices têm grandes quantidades de E/S
física.
Dica nº 1. Entenda como os índices
são usados e​​ encontre índices ruins.
O SQL Server 2012 fornece alguns dados
muito úteis sobre índices, que você pode
buscar usando DMOs implantados na
Executar um versão SQL Server 2005.
rastreamento Utilização do DMO sys.dm_db_index_
operational_stats
do Profiler no sys.dm_db_index_operational_stats
lado do servidor contém informações sobre o atual baixo
nível de E/S, bloqueio, travamento e
permitirá que atividade do método de acesso para cada
índice. Use esse DMF para responder às
você visualize a seguintes perguntas:
carga de trabalho •  Tenho um índice "favorito"? Tenho um
índice no qual existe contenção? As
do servidor e colunas row lock wait in ms/page lock wait
in ms podem nos dizer se existem esperas
selecione partes neste índice.
•  Tenho um índice que está sendo usado
de código de forma ineficiente? Quais índices estão
executadas com atualmente em gargalos de E/S? A coluna
page_io_latch_wait_ ms poderá nos dizer
frequência. se houve espera de E/S ao trazer páginas
de índice para o cache do buffer; um bom
indicador de que existe um padrão de
acesso à verificação.
Figura 6. Índices listados pela espera total de PAGE_IO_LATCH
16
•  Que tipo de padrões de acesso estão
em uso? As colunas range_scan_count
e singleton_ lookup_count podem nos
dizer quais tipos de padrões de acesso são
usados em um índice específico.
A Figura 6 ilustra a saída de uma consulta
que lista índices pela espera total
PAGE_IO_ LATCH. Isso será muito útil
ao tentar determinar quais índices estão
envolvidos em gargalos de E/S.
Utilização do DMO sys.dm_db_index_
usage_stats
sys.dm_db_index_usage_stats contém
contagens de diferentes tipos de
operações de índice e a hora que cada
tipo de operação foi executado pela
última vez. Use esse DMV para responder
às seguintes perguntas:
•  Como os usuários estão usando os
índices? As colunas user_ seeks, user_
scans, user_lookups podem informar os
tipos e o significado das operações do
usuário nos índices.
•  Qual é o custo de um índice? A coluna
user_updates pode informar qual é o nível
de manutenção para um índice.
•  Quando um índice foi usado pela última
vez? As colunas last_* podem informar a
última vez que uma operação ocorreu em
um índice.

Figura 7. Índices listados pelo número total de user_seeks
A Figura 7 ilustra a saída de uma consulta
que lista índices pelo número total de
user_seeks. Se você quis identificar índices
que tiveram uma alta proporção de
verificações, poderá ordenar pela coluna
user_scans. Agora que você tem um
nome de índice, não seria bom descobrir
quais instruções SQL usaram esse índice?
No SQL Server 2005 e versões mais
recentes, você pode fazer isso.
Há, naturalmente, muitas outras áreas
para índices, como estratégia de design,
consolidação e manutenção. Se você
quiser ler mais sobre esta área vital de
ajuste de desempenho do SQL Server, vá
até o SQLServerPedia ou confira alguns dos 6. Aprenda a usar o SQL Profiler, rastreamentos
webcasts da Dell ou white papers sobre o
assunto.
Conclusão
Claro que há muito mais que 10 coisas
que você deve saber sobre o desempenho
do SQL Server. No entanto, este white
paper oferece um bom ponto de partida e
algumas dicas práticas sobre otimização de 2. Aprenda a ler o cache de buffer do SQL
desempenho que você pode aplicar ao seu
ambiente do SQL Server.
17
Uma expectativa
de vida da
página de
menos de cinco
minutos pode
Para recapitular, lembre-se
dessas 10 coisas ao otimizar o indicar pressão
desempenho do SQL Server:
10. A referência de desempenho facilita as
de memória
comparações de comportamento da (memória
carga de trabalho e permite detectar
o comportamento anormal, pois você insuficiente) ou
tem uma boa indicação do que é um
comportamento normal.
sobrecarga no
9. Os contadores de desempenho fornecem cache.
informações rápidas e úteis sobre as
operações atualmente em execução.
8. Alterar as configurações do servidor pode
proporcionar um ambiente mais estável.
7.  DMOs ajudam você a identificar gargalos de
desempenho rapidamente.
e eventos estendidos.
5. SANs são mais do que apenas caixas pretas
que executam E/S.
4. Cursores e outro T-SQL ruim
frequentemente voltam para assombrar as
aplicações.
3. Aumente a reutilização do plano para obter
melhor caching do SQL Server.
Server e a minimizar a sobrecarga do cache.
E a dica número um para otimizar
o desempenho do SQL Server:
1. Domine a indexação aprendendo como
os índices são usados e como encontrar
índices ruins.
 Chamada para ação
Estou certo de que você está
ansioso para implementar as lições
aprendidas neste white paper.
A tabela abaixo lista as ações para
buscar um ambiente mais otimizado
do SQL Server:

Ação Subtarefas Data esperada

Obter aprovação para iniciar Fale com o seu gerente de linha e apresente o
o projeto argumento de que, com este projeto em vigor, você
pode ser proativo ao invés de reativo.
Identificar metas de desem- Fale com as partes interessadas da empresa para
penho
determinar os níveis aceitáveis de desempenho.
Usar consultas Estabelecer uma linha de
Colete dados relevantes e armazene-os em um
parametrizadas base para o desempenho do
sistema
repositório personalizado ou de terceiros.

não só melhora Identificar os principais

contadores de desempenho e
Faça download do pôster do Perfmon da Dell.

a reutilização do configurar rastreamento e/ou

eventos estendidos

plano e sobrecarga Analisar as configurações do

servidor Preste especial atenção às configurações de memória
e "Otimizar para cargas de trabalho ad hoc".
de compilação, Analisar o subsistema de E/S Se for o caso, fale com seus administradores de SAN
mas também reduz e considere realizar testes de carga de E/S usando
ferramentas como SQLIO, ou simplesmente determine
o risco de ataque a taxa na qual você pode fazer operações intensivas de
leitura e gravação, como ao realizar back-ups.

de injeção de Identificar consultas com

baixo desempenho
Analise os dados retornados a partir de rastreamentos,
sessões de eventos estendidos e cache de planos.
SQL envolvido ao Refatorar códigos com baixo Confira as melhores práticas mais recentes no
desempenho serviço de blog sindicalizado do SQLServerPedia.
analisar parâmetros Manutenção de índice Certifique-se de que seus índices sejam os melhores
possíveis.
por meio da
concatenação de
cadeias.

18
Para obter mais informações
© 2013 Dell, Inc. TODOS OS DIREITOS RESERVADOS. Este
documento contém informações proprietárias protegidas por
direitos autorais. Nenhuma parte deste documento pode ser
reproduzida ou transmitida em qualquer forma ou por qualquer
meio, eletrônico ou mecânico, incluindo fotocópia e gravação
para qualquer propósito, sem a permissão por escrito da Dell,
Inc. ("Dell").
Dell, Dell Software, o logotipo e os produtos da Dell Software,
como identificados neste documento, são marcas registradas
da Dell, Inc. nos EUA e/ou em outros países. Todas as outras
marcas comerciais ou registradas são de responsabilidade de
seus respectivos proprietários.
As informações deste documento são relativas aos produtos
Dell. Nenhuma licença, expressa ou implícita, por embargo ou
de outra forma, a qualquer direito de propriedade intelectual é
concedida por este documento ou em conjunto com a venda
de produtos Dell. EXCETO CONFORME ESTABELECIDO NOS
TERMOS E CONDIÇÕES DA DELL, CONFORME ESPECIFICADO
NO CONTRATO DE LICENÇA PARA ESTE PRODUTO,
A DELL NÃO ASSUME NENHUMA RESPONSABILIDADE,
SEJA ELA QUAL FOR, E RENUNCIA A TODA GARANTIA
EXPLÍCITA, IMPLÍCITA OU ESTATUTÁRIA RELACIONADA A
SEUS PRODUTOS, INCLUINDO, SEM LIMITAÇÃO, A GARANTIA
IMPLÍCITA DE COMERCIABILIDADE, ADEQUAÇÃO A UM
PROPÓSITO ESPECÍFICO OU NÃO VIOLAÇÃO. EM HIPÓTESE
ALGUMA A DELL SERÁ RESPONSÁVEL POR QUAISQUER
DANOS DIRETOS, INDIRETOS, CONSEQUENCIAIS, PUNITIVOS,
ESPECIAIS OU INCIDENTAIS (INCLUINDO, SEM LIMITAÇÃO,
DANOS POR PERDA DE LUCROS, INTERRUPÇÃO DE
NEGÓCIOS OU PERDA DE INFORMAÇÕES), DECORRENTES DO
USO OU IMPOSSIBILIDADE DE UTILIZAR ESTE DOCUMENTO,
MESMO QUE A DELL TENHA SIDO AVISADA DA POSSIBILIDADE
DE TAIS DANOS. A Dell não faz quaisquer representações ou
garantias com relação à exatidão ou completude do conteúdo
deste documento e se reserva o direito de fazer alterações nas
especificações e descrições de produtos a qualquer momento
sem aviso prévio. A Dell não se compromete em atualizar as
informações contidas neste documento.

Sobre a Dell
A Dell Inc. (NASDAQ: DELL) escuta seus clientes e fornece,
globalmente, soluções de negócios e tecnologias inovadoras
e serviços que eles valorizam e nos quais confiam. Para obter
mais informações, visite o site www.dell.com.

Se você tiver dúvidas sobre o possível uso deste material,

entre em contato:

Dell Software
5 Polaris Way
Aliso Viejo, CA 92656
www.dell.com
Consulte nosso site para obter informações sobre escritórios
regionais ou internacionais.

Whitepaper-TenTips-OptimSQL-US-KS-2013-04-03