Configuração e pressão de memória no SQL Server

O padrão de max server memory pode deixar Windows e outros serviços sem memória. Um valor baixo causa leituras, compilações e pressão de grants desnecessárias.

Por que este tema exige atenção deliberada

Um problema desse tipo raramente existe isolado. Uma mudança que melhora uma consulta pode aumentar escrita, log, bloqueio, recuperação ou complexidade em outro ponto. Trate o trabalho como decisão de engenharia com objetivo mensurável, restrições conhecidas e responsável claro.

Uma configuração sólida protege o host e oferece ao SQL Server memória suficiente para a carga real.

O que medir

Analise memória do processo, memória disponível, paginação, buffer, grants pendentes, esperas de workspace, stolen memory, columnstore e serviços compartilhados.

Fluxo de diagnóstico

• Defina exatamente o sintoma, carga afetada, início, frequência e impacto visível.
• Capture evidências em períodos normais e degradados para a mesma operação de negócio.
• Separe correlação de causa analisando planos, esperas, recursos, bloqueios, configuração e mudanças recentes.
• Teste grupos representativos de bancos, consultas ou parâmetros, não apenas o exemplo mais simples.
• Preserve configuração, plano, definição e contadores atuais antes de qualquer alteração.
• Expresse numericamente o resultado esperado: latência, CPU, leituras, vazão, fila ou recuperação.

Como escolher a intervenção

Prefira a menor mudança que trate a causa comprovada. Configuração do servidor afeta muitas cargas, enquanto consulta, índice, estatística ou agenda pode ser mais específica. Considere licença, versão, alta disponibilidade, janelas e capacidade de monitoramento da equipe.

Abordagem prática

Reserve capacidade para Windows, drivers, agentes, backups e outros serviços. Trate max server memory como teto, investigue grants excessivos e meça picos, manutenção e failover.

Sequência segura de implementação

• Reproduza o comportamento em ambiente seguro com dados em escala de produção.
• Altere uma variável importante por vez e preserve a definição original para reversão.
• Meça duração, CPU, leituras, escritas, esperas, memória, geração de log e efeitos posteriores.
• Teste entradas normais, picos e extremos, além de reinício ou failover quando relevante.
• Implante em janela adequada com operador, responsável da aplicação e decisor de reversão disponíveis.
• Revise imediatamente e novamente durante o próximo pico representativo.

Exemplo de SQL Server

O exemplo a seguir é um ponto de partida para investigação ou implementação controlada. Adapte nomes, limites, retenção e permissões antes da produção. Preserve a saída junto da linha do tempo do incidente e não trate uma única amostra como diagnóstico completo.

SELECT
    physical_memory_in_use_kb / 1024 AS sql_process_mb,
    locked_page_allocations_kb / 1024 AS locked_pages_mb,
    memory_utilization_percentage,
    process_physical_memory_low,
    process_virtual_memory_low
FROM sys.dm_os_process_memory;

SELECT COUNT(*) AS pending_memory_grants
FROM sys.dm_exec_query_memory_grants
WHERE grant_time IS NULL;

O que evitar

Não use uma fórmula fixa para todos, não avalie pressão apenas por Page Life Expectancy e não ignore memória fora do buffer pool.

Monitoramento após a mudança

Acompanhe a métrica que deveria melhorar e pelo menos dois possíveis efeitos colaterais. Compare janelas e volumes equivalentes. Observe tempo suficiente para incluir manutenção, backups, relatórios, failover e atividades periódicas. Documente se a melhoria persistiu e se a mudança deve permanecer, ser ajustada ou removida.

Reversão e responsabilidade

A reversão deve informar valor ou definição anterior, quem decide e qual sinal dispara a volta. Preserve plano e script originais em mudanças de plano ou metadados. Para infraestrutura, confirme capacidade e tempo de manutenção antes de iniciar.

Resultado operacional

Uma configuração sólida protege o host e oferece ao SQL Server memória suficiente para a carga real.

Checklist de produção

Registre uma linha de base e defina a melhoria esperada. Teste com dados e concorrência representativos. Preserve a configuração ou o plano original, prepare uma reversão, implante em uma janela adequada e acompanhe o próximo pico normal de carga.

Perguntas antes de encerrar

• O sintoma original melhorou sob a mesma carga?
• Surgiram custos de escrita, armazenamento, bloqueio, memória ou disponibilidade?
• O resultado sobreviverá a reinício, failover, estatísticas e crescimento?
• Os alertas detectarão regressão antes dos usuários?
• A decisão, o responsável e a data de revisão foram registrados?

Para aplicar esse método a um ambiente SQL Server específico, use o formulário abaixo e informe a versão, o tamanho do banco, o perfil da carga e as evidências já coletadas.