Dez dicas para otimizar o desempenho do SQL Server

Dez dicas para otimizar o
desempenho do SQL Server
Escrito por Patrick O’Keefe e Richard Douglas
Resumo
Introdução
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.
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.
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?
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
Trabalhe para
aumentar a
escalabilidade e
a eficiência de
todos os servidores
de banco de
dados, mesmo se
os requisitos de
negócios estiverem
sendo cumpridos.
Lembre-se de que o ajuste é um processo
contínuo, não uma correção única.
A otimização de desempenho é um
processo contínuo. Por exemplo, ao
ajustar para metas de SLA, será possível ter
"concluído". No entanto, se você estiver
ajustando para aumentar a eficiência ou
garantir a escalabilidade, seu trabalho
nunca será realmente concluído; esse tipo
de ajuste deve ser continuado até que o
desempenho esteja "bom o suficiente".
No futuro, quando o desempenho da
aplicação não for mais bom o suficiente,
o ciclo de ajuste deverá ser executado
novamente.
Dica nº 10. A metodologia de criação
de linha de base e referência de
desempenho ajuda você a detectar
os problemas.
Visão geral do processo de criação
de linha de base e referência de
desempenho A Figura 1 ilustra as
etapas no processo de criação de linha
de base. As seções a seguir explicarão
as principais etapas no processo.
"Boa o suficiente" geralmente tem a ver
com os imperativos de negócios, como
SLAs ou requisitos de taxa de transferência
do sistema. Além desses requisitos, você
deve estar motivado para aumentar a
escalabilidade e a eficiência de todos os
servidores do banco de dados, mesmo
que os requisitos de negócios estejam
sendo cumpridos.
Sobre este documento
A otimização do desempenho no SQL
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ê
precisa coletar dados suficientes durante
um período de tempo suficientemente
longo para dar uma amostra
representativa do desempenho típico
do sistema. Assim que tiver os dados,
você pode calcular a média dos valores
durante o período para estabelecer sua
primeira linha de base. Depois de fazer
modificações no sistema, você terá
uma nova referência de desempenho e
a comparará com a original para poder
medir objetivamente o efeito de suas
alterações.
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).
A referência de
desempenho ajuda
a identificar um
comportamento
anormal, porque
você tem uma boa
indicação do que é
um comportamento
normal.
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.
Sua missão não é
obter o máximo
desempenho
possível; é conseguir
o melhor ajuste
possível para
suas metas de
desempenho e, em
seguida, limitar o
desvio dessas metas
o máximo possível.
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
a carga varia ao longo do tempo.
Converse com os administradores
de sistema, usuários finais e
administradores de aplicações. Eles
geralmente têm uma boa noção de
quais são os padrões de uso. Você deve
reunir dados suficientes para cobrir
períodos fora de pico, médios e de pico.
É importante medir a quantidade que
varia de carga e com que frequência.
Os sistemas com padrões previsíveis
exigirão menos dados. Quanto maior a
variação, menor o intervalo de medição
e maior o tempo que você precisará
para medir e desenvolver uma linha de
base confiável. Para ir um pouco mais
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.
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
ajuste de desempenho. Ela fornece o
mapa, uma referência e os pontos de
interesse necessários para descobrirmos
onde precisamos ir e como chegar
lá, para nos ajudar a garantir que não
nos perderemos no caminho. Uma
abordagem estruturada nos permite criar
um desempenho confiável e consistente
em todo nosso portfólio do banco de
dados.
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?
5
A quantidade de
dados necessários
para estabelecer
uma linha de base
depende de como a
carga varia ao longo
do tempo.
Você também pode usar os dados para
fins de tendência. Um bom exemplo seria
coletar os tamanhos de todos os arquivos
de dados para direcionar suas taxas de
crescimento e prever futuras necessidades
de recursos.
Limite o número
de alterações
feitas entre cada
referência de
desempenho, para
que possa avaliar
meticulosamente
os efeitos de cada
mudança.
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
Memory\Available MBytes
Ver a quantidade de memória física disponível para
uso do sistema
Monitorar os contadores de desempenho
para evitar gargalos
O monitoramento de gargalos se
concentra mais em questões relacionadas
ao desempenho. Os dados coletados
ajudam a responder a perguntas, tais
como:
• Os principais subsistemas do SQL
Server, como o cache de buffer e
cache de planos estão íntegros?
• Existe contenção no banco de dados?
Para responder a essas perguntas,
analise os seguintes contadores:
• Existe um gargalo da CPU?
• Existe um gargalo de E/S?
Medidor
Permite a você
Processor\%Processor Time
Monitorar o consumo da CPU permite que você
verifique se há um gargalo no servidor (indicado pelo
alto uso sustentado).
Alta porcentagem de espera de sinal
Disco físico\média Tamanho da fila do disco
6
Para responder às três perguntas feitas
acima, você deve analisar os seguintes
contadores:
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.
MSSQL$Instance:Buffer Manager\Page Life
Expectativa
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.
MSSQL$Instance:Plan Cache\Cache Hit Ratio
Uma baixa taxa de acertos do cache de planos
significa que os planos não estão sendo reutilizados.
MSSQL$Instance:General Statistics\Processes
Blocos
Blocos longos indicam contenção de recursos.
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
especificamente, apenas alocações de
página única de 8 KB). Isso significa que se
você executasse processos fora do pool de
buffers (como procedimentos armazenados
estendidos, CLR ou outros componentes,
como Integration Services, Reporting
Services ou Analysis Services), você
precisaria reduzir ainda mais esse valor.
• SQL Server 2012 — O SQL Server 2012
muda um pouco as coisas quando há um
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.
Sage aconselha
sobre como
solucionar
problemas em
apenas três
palavras: "Eliminar
ou incriminar".
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).
Monitorar os
contadores de
desempenho pode
ajudar a aumentar
a eficiência
operacional e evitar
gargalos.
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:
SELECT TOP 50
qs.total_worker_time / execution_count AS avg_worker_time,
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
avg_worker_time DESC
A parte realmente útil dessa consulta é
sua habilidade de usar aplicação cruzada
e sys.dm_exec_sql_text para obter a
instrução SQL para analisá-la.
Diagnosticar um gargalo de E/S A
história é semelhante para um gargalo
de E/S:
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.
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.
3.
Abra o Profiler.
4.Crie um novo rastreamento especificando
os detalhes sobre a instância, os eventos
e as colunas que você deseja monitorar,
bem como o destino.
5.
Inicie o rastreamento.
6.Retorne para o Perfmon para iniciar o
coletor de dados definido.
7.Deixe ambas as sessões executando
até que os dados necessários sejam
capturados.
8.Pare o rastreamento do Profiler. Salve o
rastreamento e, em seguida, feche-o.
9.Volte para o Perfmon e pare a coleta de
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.
9
O monitoramento
operacional
verifica o uso geral
de recursos. O
monitoramento
de gargalos se
concentra mais
em questões
relacionadas ao
desempenho.
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.
Figura 2. Uma visão correlacionada de contadores de desempenho em conjunto com o
arquivo de rastreamento do Profiler
Dica nº 5. Configure SANs para
desempenho do SQL Server.
As redes de área de armazenamento (SANs)
são fantásticas. Elas oferecem a capacidade
de provisionar e gerenciar o armazenamento
de uma forma simples. SANs podem ser
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]
FROM sys.dm_io_virtual_file_stats (NULL, NULL) a
JOIN sys.master_files b
ON a.file_id = b.file_id AND a.database_id = b.database_id
ORDER BY a.io_stall DESC;
Análise dos dados
Preste atenção especial ao valor
"LastReset" na consulta; ele mostra a
última vez que o serviço do SQL Server
foi iniciado. Os dados de objetos de
gerenciamento dinâmico não são
persistentes, então, quaisquer dados
sendo usados para fins de ajuste devem
ser validados em relação ao tempo de
execução do serviço, caso contrário,
podem ser feitas falsas suposições.
Ao usar esses números, você poderá
rapidamente restringir quais arquivos são
responsáveis ​​pelo consumo da largura de
banda de E/S e fazer perguntas como:
• Este E/S é necessário? Está faltando um
índice?
• Será que uma tabela ou índice em um
arquivo é responsável? Posso colocar esse
índice ou tabela em outro arquivo em outro
volume?
Dicas para ajustar seu hardware se os
arquivos de banco de dados estiverem
corretamente colocados e todos os
pontos de acesso de objetos tiverem
sido identificados e separados em
diferentes volumes, então, estará na
hora de dar uma olhada no hardware.
Ajustar o hardware é um tema
especializado fora do escopo deste
white paper. Porém, há algumas
melhores práticas e dicas que eu posso
compartilhar com você para tornar isso
mais fácil:
• Não use o tamanho da unidade de
alocação padrão ao criar volumes para
usar com o SQL Server. O SQL Server usa
extensões de 64 KB, então, esse valor
deve ser o mínimo.
• Veja se suas partições estão alinhadas
corretamente. Jimmy May escreveu
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
Configurar backups
para que sejam
compactados por
padrão reduz a
contenção de E/S.
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.
O SQL Profiler
ainda pode
fornecer grandes
informações sobre
o funcionamento
de aplicações em
tempo real para
muitos ambientes
do SQL Server.
2.Aceite a expressão de parâmetro a ser
removida.
3.Descubra o tamanho da expressão.
4.Carregue a expressão em uma variável.
5.Execute um ciclo com cada caractere na
variável e verifique se esse caractere combina
com um dos valores a ser removido. Se
combinar, atualize a variável para removê-la.
6.Siga para o próximo caractere até que a
expressão seja completamente verificada.
Se você estiver horrorizado, então, somos
dois. É claro que estou explicando a
tentativa de alguém de escrever sua própria
instrução "REPLACE" do T-SQL!
A pior parte é que essa função foi utilizada
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).
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
Figura 4. Exemplo de um grande plano de consulta
12
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.
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á
Criar um plano de consulta pode exigir CPU
significativa. Assim, o SQL Server será executado sendo compilado, e não há nenhuma
reutilização de plano.
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
Um problema comum é que o
código não está usando instruções
parametrizadas preparadas. Usar
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.
SANs podem ser
configurados para
um desempenho
rápido a partir de
uma perspectiva
do SQL Server,
mas muitas vezes
não são.
Ruim
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
de banda de E/S.
Bom
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
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 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.
A definição de configuração ausente
na Dica nº 8
Dica nº 2. Aprenda a ler o cache de
buffer do SQL Server e minimizar a
sobrecarga do cache.
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
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:
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
• Várias páginas podem ser lidas e escritas em
de aviso de 300 segundos (cinco minutos)
uma operação de E/S.
para Expectativa de vida da página incorre
• A leitura antecipada pode ser implementada.
em um debate semelhante na comunidade
O SQL Server pode notar que para
do SQL Server: alguns acreditam que esta é
determinados tipos de operações, pode ser
uma regra dura e rápida, enquanto outros
útil ler páginas em sequência, supondo que
acreditam que o aumento da capacidade
logo depois de ler a página solicitada, você
de memória na maioria dos servidores nos
vai querer ler a página adjacente.
dias de hoje significa que o valor deve ser
Nota: a fragmentação de índice prejudicará de milhares e não centenas. Essa diferença
de opinião destaca a importância das linhas
a capacidade do SQL Server de executar a
de base e por que é tão importante ter uma
otimização de leitura antecipada.
compreensão detalhada do que os níveis
Avaliação da integridade do cache de
de alerta de cada contador de desempenho
buffer
deve ser no seu ambiente,
Há duas indicações da integridade do
cache de buffer:
Sobrecarga do cache
• Taxa de acertos do cache
Durante uma grande verificação de tabela
MSSQL$Instance:Buffer Manager\Buffer —
ou índice, cada página na verificação deve
Esta é a relação de páginas encontradas no
passar pelo cache de buffer, o que significa
cache e páginas não encontradas no cache
que páginas possivelmente úteis serão
(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
provavelmente não serão lidas mais de
o mais alto possível. É possível ter uma alta
uma vez. Isto gera alto índice de E/S já
taxa de acertos, mas ainda experimentar a
que as páginas despejadas devem ser lidas
sobrecarga do cache.
no disco novamente. Esta sobrecarga de
• MSSQL$Instance:Buffer Manager\Expectativa cache é geralmente uma indicação de que
de vida da página — Esta é a quantidade
grandes tabelas ou índices estão sendo
de tempo que o SQL Server está mantendo
verificados.
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.
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
Se os arquivos
de banco de
dados estiverem
corretamente
colocados e todos
os pontos de acesso
de objetos tiverem
sido identificados
e separados em
diferentes volumes,
então é hora de
dar uma olhada no
hardware.
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.
Executar um
rastreamento
do Profiler no
lado do servidor
permitirá que
você visualize a
carga de trabalho
do servidor e
selecione partes
de código
executadas com
frequência.
O SQL Server 2012 fornece alguns dados
muito úteis sobre índices, que você pode
buscar usando DMOs implantados na
versão SQL Server 2005.
Utilização do DMO sys.dm_db_index_
operational_stats
sys.dm_db_index_operational_stats
contém informações sobre o atual baixo
nível de E/S, bloqueio, travamento e
atividade do método de acesso para cada
índice. Use esse DMF para responder às
seguintes perguntas:
• Tenho um índice "favorito"? Tenho um
índice no qual existe contenção? As
colunas row lock wait in ms/page lock wait
in ms podem nos dizer se existem esperas
neste índice.
• Tenho um índice que está sendo usado
de forma ineficiente? Quais índices estão
atualmente em gargalos de E/S? A coluna
page_io_latch_wait_ ms poderá nos dizer
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.
• 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 6. Índices listados pela espera total de PAGE_IO_LATCH
16
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.
Para recapitular, lembre-se
dessas 10 coisas ao otimizar o
desempenho do SQL Server:
10.A referência de desempenho facilita as
comparações de comportamento da
carga de trabalho e permite detectar
o comportamento anormal, pois você
tem uma boa indicação do que é um
comportamento normal.
9.Os contadores de desempenho fornecem
informações rápidas e úteis sobre as
operações atualmente em execução.
Há, naturalmente, muitas outras áreas
8.Alterar as configurações do servidor pode
para índices, como estratégia de design,
proporcionar um ambiente mais estável.
consolidação e manutenção. Se você
7.
DMOs ajudam você a identificar gargalos de
quiser ler mais sobre esta área vital de
desempenho rapidamente.
ajuste de desempenho do SQL Server, vá
até o SQLServerPedia ou confira alguns dos 6.Aprenda a usar o SQL Profiler, rastreamentos
e eventos estendidos.
webcasts da Dell ou white papers sobre o
5.SANs são mais do que apenas caixas pretas
assunto.
que executam E/S.
Conclusão
4.Cursores e outro T-SQL ruim
frequentemente voltam para assombrar as
Claro que há muito mais que 10 coisas
aplicações.
que você deve saber sobre o desempenho
3.Aumente a reutilização do plano para obter
do SQL Server. No entanto, este white
melhor caching do SQL Server.
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
Server e a minimizar a sobrecarga do cache.
desempenho que você pode aplicar ao seu
ambiente do SQL Server.
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.
17
Uma expectativa
de vida da
página de
menos de cinco
minutos pode
indicar pressão
de memória
(memória
insuficiente) ou
sobrecarga no
cache.
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:
Usar 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.
18
Ação
Subtarefas
Obter aprovação para iniciar
o projeto
Fale com o seu gerente de linha e apresente o
argumento de que, com este projeto em vigor, você
pode ser proativo ao invés de reativo.
Identificar metas de desempenho
Fale com as partes interessadas da empresa para
determinar os níveis aceitáveis de desempenho.
Estabelecer uma linha de
base para o desempenho do
sistema
Colete dados relevantes e armazene-os em um
repositório personalizado ou de terceiros.
Identificar os principais
Faça download do pôster do Perfmon da Dell.
contadores de desempenho e
configurar rastreamento e/ou
eventos estendidos
Analisar as configurações do
servidor
Preste especial atenção às configurações de memória
e "Otimizar para cargas de trabalho ad hoc".
Analisar o subsistema de E/S
Se for o caso, fale com seus administradores de SAN
e considere realizar testes de carga de E/S usando
ferramentas como SQLIO, ou simplesmente determine
a taxa na qual você pode fazer operações intensivas de
leitura e gravação, como ao realizar back-ups.
Identificar consultas com
baixo desempenho
Analise os dados retornados a partir de rastreamentos,
sessões de eventos estendidos e cache de planos.
Refatorar códigos com baixo
desempenho
Confira as melhores práticas mais recentes no
serviço de blog sindicalizado do SQLServerPedia.
Manutenção de índice
Certifique-se de que seus índices sejam os melhores
possíveis.
Data esperada
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,
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
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.