Por que eu devo ler este artigo:Com a análise de informações sobre eventos de espera, é possível identificar gargalos de performance do seu servidor e direcionar os esforços na otimização de consultas. Também é possível traçar perfis de utilização do seu ambiente e identificar qual o melhor aproveitamento das janelas diárias para execução de rotinas batch sem prejudicar o ambiente produtivo. Para entender como isto pode ser feito, este artigo trata da análise dos eventos de espera do seu servidor SQL Server e de como podemos utilizar essas informações em análises de desempenho e performance, direcionando nossos esforços para a otimização de consultas ou até mesmo o upgrade de nossos servidores.

O desempenho das aplicações é tema recorrente em qualquer empresa, independente de seu porte, do tipo de ambiente e do perfil dos softwares que são executados.

Para medir o desempenho da aplicação, temos uma série de ferramentas que nos auxiliam a identificar problemas, minimizar gargalos e consequentemente melhorar continuamente o comportamento de nossos sistemas. Podemos citar como exemplo os contadores do performance monitor (perfmon), os traces do próprio SQL Server que nos direcionam para as consultas mais lentas ou que consomem mais recursos e também os Eventos de Espera (Wait Events) do nosso servidor de banco de dados.

E é sobre esse último item que falaremos nesse artigo. O que são os eventos de espera? Como coletar essas informações? O que elas nos dizem? Quais eventos devem ser tratados com mais atenção e quais podem ser descartados na minha análise? Responderemos essas perguntas ao decorrer do artigo.

O que são os eventos de espera?

Sempre que o banco de dados aguarda por algum recurso para que um determinado processamento seja concluído, essa informação é registrada. A espera pode ser por CPU, por disco, por escrita, não importa. Qualquer espera para que uma ação seja concluída é armazenada. Esses são os chamados eventos de espera. Analisando essas informações podemos determinar se temos uma grande espera por lock, por exemplo, se temos problemas com paralelismo de consultas ou com escrita ou leitura de disco. Isso nos ajuda no direcionamento dos trabalhos de performance.

Onde ficam essas informações e como acessá-las?

Os eventos de espera são registrados de forma crescente no servidor e só são zerados após uma reinicialização do sistema. Dessa forma, uma foto dos eventos de espera do banco de dados de agora é sempre maior que uma de minutos atrás.

Para obter essas informações existem duas maneiras:

· Através do comando DBCC:

DBCC sqlperf (waitstats)

· Por meio da view DM_OS_WAIT_STATS:

select * from sys.dm_os_wait_stats

Embora ligeiramente diferentes, os comandos acima retornam as mesmas informações. Devemos, no entanto, manter nosso foco nas seguintes:

· Wait Type: Nome do evento de espera;

· Wait Time: Tempo acumulado de espera do evento.

Com essas informações temos os eventos e o tempo de espera acumulado desde a última inicialização do serviço de banco de dados.

Todos os eventos são importantes?

É difícil elencar eventos que sempre aparecerão em suas análises. Pensando em priorizar nossa atenção, é mais simples eliminarmos eventos que não têm relação com o tempo de resposta de nossa aplicação. Eventos do tipo Sleep e também Waitfor podem ser desconsiderados imediatamente por não influenciarem o tempo de resposta de nossas aplicações. Além desses, geralmente os eventos de sistema, como checkpoints do banco ou a limpeza da fila de processos são eventos que podem ser desconsiderados da análise.

Na Tabela 1 te ...

Quer ler esse conteúdo completo? Tenha acesso completo