Como resolver os tipos de espera RESOURCE_SEMAPHORE e RESOURCE_SEMAPHORE_QUERY_COMPILE

Estamos tentando descobrir a causa raiz das consultas de servidor sql em execução lenta, que atingem / buscam dados de um banco de dados, tamanho 300 GB, hospedado no servidor com a configuração abaixo:

Servidor Windows 2003 R2, SP2, Enterprise Edition, 16 GB de RAM, 12 bits de CPU 32

SQL Server 2005, SP4, Enterprise Edition, 32 bits.

Já informamos os negócios sobre a atualização para 64 bits, o que levaria mais de um mês.

Mas para o problema atual, estamos tentando coletar os dados se pudermos resolver a pressão da memória ou finalmente chegar a uma conclusão para aumentar a RAM.

Ação concluída: a indexação e as estatísticas de atualização são adequadas para esse banco de dados.

Conforme mostrado abaixo, observamos o tipo de espera do semáforo nos últimos 5 dias, executado durante o horário de carregamento:

Poucas informações após as consultas abaixo: size of buffer = 137272

SELECT SUM(virtual_memory_committed_kb)
FROM sys.dm_os_memory_clerks
WHERE type='MEMORYCLERK_SQLBUFFERPOOL'

e memória de semáforo = 644024 por consulta abaixo

 SELECT SUM(total_memory_kb)
FROM sys.dm_exec_query_resource_semaphores

Abaixo estão mais algumas informações coletadas dm_exec_query_resource_semaphorese sys.dm_exec_query_memory_grantsdmv's

Portanto, a partir das informações acima reunidas e por dados SP_Blitz, o semáforo de recursos parece ser o problema.

A memória 'target_memory_kb' é atribuída para os IDs de semáforo de recursos muito baixos, em comparação com 16 GB de RAM disponível.

Nota * por análise em 8 horas de execução, 'target_memory_kb' é sempre inferior a 1 GB, em comparação com 16 GB disponíveis?

qual poderia ser o problema aqui e como resolver, sugira

obrigado

Oh, Deus, eu tenho más notícias aqui.

Em um sistema operacional de 32 bits, o SQL Server usa apenas os primeiros 4 GB de memória para itens como espaço de trabalho de consulta. (E também está lutando contra o sistema operacional por esses 4 GB - quaisquer outros aplicativos em execução também competirão por essa memória.)

4 GB pode parecer muito, mas é relativamente fácil escrever uma consulta que precise de vários GB de memória para ser executada. Quando consultas suficientes exigem memória suficiente, o SQL Server lança RESOURCE_SEMAPHORE aguarda porque as consultas não conseguem obter memória suficiente para iniciar. RESOURCE_SEMAPHORE_QUERY_COMPILE significa que eles não conseguem nem ter memória suficiente para compilar um plano de execução - e sim, isso é muito ruim.

Então, como você conserta isso?

• Alterne para um sistema operacional de 64 bits (o sistema operacional em execução está sem suporte há muito tempo)
• Alterne para uma compilação de 64 bits do SQL Server
• Reduza as demandas de memória no servidor (não execute outros aplicativos nesta caixa, e isso é especialmente crítico em caixas de 32 bits, pois estamos limitados a apenas 4 GB)
• Use mais memória com as opções AWE / PAE - exceto que não funciona para RESOURCE_SEMAPHORE aguarda porque o SQL Server pode usar apenas os primeiros 4 GB para o espaço de trabalho da consulta
• Ajuste consultas e índices para que eles precisem de menos memória

Hesito em dizer o último, porque o problema de 32 bits é muito ruim e é muito difícil nas versões mais antigas do SQL Server. Se você estivesse em uma versão atual, poderá percorrer o cache do plano e classificar as consultas por concessão de memória, encontrar os maiores destinatários da concessão e ajustá-los. Não é uma opção nesta antiguidade, no entanto.