Configurando instâncias do SQL Server

Atualmente, muitas empresas possuem instâncias SQL Server em seus servidores, porém nem sempre as instalações destas instâncias são realizadas por um especialista em banco de dados, e consequentemente as opções defaults são utilizadas. Entretanto, algumas outras opções que poderiam ajudar em uma futura manutenção passam despercebidas pelo usuário.

Essa “falta de conhecimento” ao se instalar instâncias do SQL Server faz com que algumas opções essenciais para o bom funcionamento não sejam devidamente configuradas, e isso pode consequentemente, gerar sérios problemas e até prejuízos para a empresa (inclusive financeiros), que poderão demandar a intervenção de uma pessoa mais especializada, como um DBA.

Assim, à medida que os problemas vão acontecendo como, por exemplo, lentidão ao se manipular uma tabela, acaba tornando-se necessário a utilização de algumas configurações existentes no SQL Server, a fim de solucioná-los ou pelo menos amenizá-los.

Contudo, não existe um padrão fixo de regras a serem seguidas para a resolução de problemas como lentidão em um servidor, pois sempre irão existir vários fatores que tornarão cada cenário único, como: a carga de dados exercida no banco de dados, a configuração desta máquina, a quantidade de usuários que estão utilizando a base de dados simultaneamente, entre outros.

Por isso, iremos abordar algumas opções de configuração existentes em uma instância SQL Server que possam ajudar na solução de problemas diários de um DBA.

Para ilustrar o artigo, utilizaremos como exemplo uma instalação do SQL Server 2012 Enterprise realizada da forma padrão, sem nenhum tipo de configuração adicional feita, instalada em um servidor com sistema operacional Windows Server 2012 Enterprise, e demonstraremos como realizar alguns ajustes que possam ajudar na manutenção deste servidor.

Conceitos iniciais sobre instâncias SQL Server

Uma instância do SQL Server pode ser entendida como um contêiner onde colocamos nossos bancos de dados. Ao configurarmos uma instância no SQL Server, podemos alterar a forma como o hardware pode reagir a diversas situações dentro do ambiente como, por exemplo, se vai utilizar mais de um processador para determinadas consultas ao banco de dados ou se deve utilizar uma quantidade de memória limitada para não comprometer o uso de outros aplicativos que utilizam o mesmo servidor.

Vale ressaltar que mesmo após se configurar uma instância, alterando suas opções padrões, esta poderá ser sobreposta por uma configuração realizada por um usuário em uma sessão independente.

Por exemplo, se o DBA configurar a instância para sempre realizar o backup de forma compactada, isso não impedirá que um outro usuário, logado nesta mesma instância, e que tenha permissão para realizar backups, possa realizá-lo sem essa compactação por padrão.

As configurações “Default” em uma instalação SQL Server funcionam satisfatoriamente bem na grande maioria dos cenários devido ao fato de serem previamente calculadas para padrões de utilização normais, onde não há excesso de requisições, utilização excessiva de seus recursos, entre outros.

Porém, quando há um grande volume de I/O, de requisições e de aplicações utilizando os bancos nessa instância SQL Server, surge a necessidade de se aplicar alguns ajustes pontuais.

Um exemplo disso ocorre quando um servidor SQL Server compartilha memória com outros aplicativos, inicialmente ele não pode prever e tampouco limitar qual será a alocação de memória para estes, acarretando assim um alto nível de consumo de memória nos momentos de pico.

Porém é muito importante que qualquer configuração realizada seja feita com o máximo de cuidado, e se possível testada antes, pois na maioria das vezes, ela surgirá com a necessidade de se fazê-las em um momento crítico, como em um gargalo no servidor no momento de pico, ou na manutenção de um banco de dados de um cliente que está sem acesso a essa base devido ao fato do banco estar corrompido."