Com o SQL Server 2005 temos mais de 201 tipos de de Waits, onde cada um desses descreve e demonstra um tipo de situação pelo qual o banco de dados está aguardando.

 

Neste "post", gostaria de descrever um deles, e exemplificar utilizando situações pelas quais passei.

 

 

Este final de semana precisamos migrar algumas tabelas para um novo modelo utilizando particionamento de dados, tendo em vista que o banco de dados trata-se de um VLDB (Very Large Database), fizemos o planejamento e utilizamos pacotes SSIS para copiar os dados em paralelo para a nova estrutura, usando essa metodologia conseguimos carregar milhões de registros em questões de minutos. Esse é tema para outro "post".

 

Em duas dessas tabelas identificamos a seguinte situação:

 

Usamos as DMV's sys.dm_exec_requests e sys.dm_exec_sessions para verificarmos a sessão e o tipo de wait que está ocorrendo, exemplo:

 

Select *

From    sys.dm_exec_requests

Where  spid = @spid

 

Ao executarmos diversas queries para obtermos os dados, vivenciamos RESOURCE_SEMAPHORE no SQL Server, pesquisamos e analisamos o que estava ocorrendo. Verificamos que esse evento ocorre quando existe "Memory Pressure", quando o SQL Server detecta essa situação ele entra em um estado de "dormência" até que tenha memória disponível para processar outras solicitações.

 

Esse evento ocorreu duas vezes conosco, em uma dessas situações identificamos que o problema tratava-se da query que estava sendo executada, essa estava realizando um "Hash Join", onde este consumia memória demais, foi então que decidimos inserir um "Hint" na query para utilizar um índice válido, pois o otimizador não estava utilizando-o, provavelmente por falta de estatísticas no banco, porém não tinhamos muito tempo para gerar as estatísticas novamente, essa tabela é grande demais.

 

O segundo evento ocorreu em outra tabela com uma consulta já otimizada, neste outro caso resolvemos o problema quebrando os  "data flow tasks" para processar menor quantidade de registros por vez, pelo fato de termos milhões de registros por dia a query torna-se pesada para subir os dados para a memória.

 

 

Sempre analise o plano de execução das queries, verifique se o otimizador está utilizando o índice correto, quando necessário altere a lógica da sua query para torná-la otimizada e observe o comportamento do SGBD e do sistema operacional afim de identificar onde é o gargalo, eventos de "Memory Pressure" nem sempre são fáceis de serem identificados, por isso muita vezes é necessário uma investigação mais profunda caso a caso.

 

 

 

Abraços,

 

Rodrigo Fernandes