SQL Server: quanto mais memória, melhor

A utilização do SQL Server no mesmo servidor que está executando outras aplicações merece atenção para o gerenciamento do consumo de memória. Este artigo traz algumas informações sobre como ajustar manualmente as configurações de memória do servidor de banco de dados SQL Server.

por Walter Carlin Junior

Embora ainda exista em alguns cenários corporativos, já é finado o tempo das aplicações stand alone, com programas executáveis escritos em Clipper e Basic e com bases de dados em frágeis arquivos sem gerenciamento. Mas uma coisa era certa: essas aplicações davam conta do recado – e com louvor. Quem tem vinte anos ou mais desenvolvendo software deve se lembrar disso. Com o começo dos anos 90 também iniciou um problema que estava fadando essas aplicações ao descanso eterno: a barreira dos 640 KB de memória baixa do sistema operacional. Os aplicativos em Clipper já estavam começando a estourar a memória e tinham que ser compilados gerando overlays - que podemos a grosso modo comparar com as atuais DLLs - para permitir que toda aquela absurda quantidade de 640 KB de memória fosse suficiente. Era praticamente impossível imaginar que duas décadas depois estaríamos falando que 4 GB de memória seriam encontrados em notebooks à venda em lojas de departamentos.

Passamos para a era das aplicações gerenciadas, plataformas escalonáveis e integrações infinitas através de web services. As tabelas livres deram lugar aos bancos de dados relacionais administrados por SGBDR - Sistema Gerenciador de Banco de Dados Relacional – do  inglês Relational Database Management System (RDBMS). No meio de tanta informação espalhada pelo mundo, o mesmo problema de 20 anos atrás começou a apontar novamente na cabeça dos profissionais de TI: “será que a memória do meu servidor é suficiente?”

É notório que em uma infraestrutura adequada cada tipo de recurso esteja em seu devido lugar. Vamos citar como exemplo o caso de uma aplicação web ASP.NET suportada por um banco de dados SQL Server 2008. Esta aplicação utilizará recursos que são peculiares de pelo menos dois tipos de servidores: o IIS – Internet Information Server, servidor web para hospedar a aplicação, e o SQL Server, para suprir as necessidades de manipulação de dados. Nem vamos ainda atentar para o fato de outros recursos do sistema operacional. O melhor cenário para esta aplicação seria separar o trabalho em pelo menos dois servidores: um para o servidor de banco de dados e outro para o servidor web.

O principal motivo para esta estratégia é a concorrência de recursos. O SQL Server por padrão é configurado para usar a memória dinamicamente baseado nos recursos de sistema disponíveis. Isto significa que quanto mais memória para ele, melhor. Utilizando dinamicamente a memória, o SQL Server consulta o sistema operacional periodicamente para determinar a quantidade de memória física disponível. Quando executado sobre o Windows Server 2003, ele faz uso da API QueryMemoryResourceNotification para determinar quando precisa alocar e liberar memória, consultando periodicamente o sistema operacional.

É recomendável que o SQL Server gerencie dinamicamente a memória. Este caso atende ao citado acima, a respeito da concorrência de recursos. Se o servidor for exclusivo para o SQL Server, então o consumo máximo de memória não deverá ser um problema, pois não haverá outras aplicações concorrendo no mesmo servidor. Mas se estivermos falando de uma pequena empresa com somente um servidor hospedando todas as aplicações, isto pode ser realmente um problema. O fato é que o SQL Server alocará o máximo de memória que conseguir, fazendo com que outras aplicações se arrastem para processar ou simplesmente não iniciem por falta de memória. E se iniciarem, poderá aumentar a paginação do sistema operacional.

Neste cenário é interessante ajustar as opções de memória do SQL Server manualmente. Antes de tudo tenha em mente quanto de memória cada aplicação que será hospedada no servidor necessita. Determine a memória por subtração, ou seja, do total de memória física do servidor subtraia o consumo aproximado do sistema operacional Windows Server, das demais instâncias de bancos de dados e demais aplicações residentes em memória ou que necessitem de iniciar em tempos determinados. O que restar desta diferença é a memória que você poderá dedicar ao SQL Server.

Nas bases de conhecimento da Microsoft há duas opções de memória do servidor para reconfigurar a quantidade de memória, em megabytes, do buffer utilizado por uma instância do SQL Server: min server memory e max server memory.

O valor padrão para min server memory é 0 (zero) e para max server memory é 2.147.483.647. O valor mínimo que pode ser especificado para max server memory é 16 MB. Mas sinceramente, quem deixaria somente 16 MB (isso mesmo, megabytes) de memória para o banco de dados? Se fosse no início dos anos 90, isso seria uma maravilha.

Há dois métodos principais para ajustar a memória manualmente no SQL Server:

· Ajustar um valor fixo de memória: ajuste min server memory e max server memory para o mesmo valor, que implica em fixar uma quantidade de memória para alocar ao buffer do SQL Server.

· Ajustar uma faixa de memória: ajuste min server memory e max server memory para uma faixa de valores mínimo e máximo de memória. Esta forma permite um pouco mais de flexibilidade para configurar uma instância do SQL Server em conjunto com outros requisitos de memória para outras aplicações que compartilham o mesmo servidor.

Utilize min server memory para certificar que uma quantidade mínima de memória fique dedicada ao buffer para a instância do SQL Server em questão. Mesmo especificando um valor mínimo, o SQL Server não alocará o total desta memória imediatamente no início se este valor for relativamente mais alto, mas depois que o valor mínimo for alcançado, ele não liberará memória para um valor abaixo do especificado em min server memory. Embora pareça contraditório, o SQL Server pode não alocar a quantidade especificada em min server memory se a carga do servidor nunca atingir este valor. Se isto ocorrer, o SQL Server executará com menos memória do que o indicado como mínimo.

Naquele cenário de um único servidor compartilhado, vamos supor que este hardware possui 12 GB de memória física instalada, que deverá ser compartilhada entre a aplicação web e o banco de dados. Veja um exemplo de como configurar uma instância do SQL Server para executar com o máximo de 8 GB (ou 8192 MB) de memória, deixando o restante livre para o Internet Information Server e os demais recursos do sistema operacional, através de um código Transact-SQL executado via SQL Server Management Studio:

sp_configure "show advanced options", 1;

GO

RECONFIGURE;

GO

sp_configure "max server memory", 8192;

GO

RECONFIGURE;

GO

Este código fixou um valor máximo de 8192 MB para execução desta instância do SQL Server. Depois disso, você ainda é capaz de lembrar dos 640 KB do MS-DOS?