Skip to content

DBCC SHRINKFILE para diminuir tamanho log no Sql Server

Há algum tempo estamos tendo problema com a base ASPSTATE no Sql Server. Cheguei a fazer um post aqui no blog sobre os problemas que enfrentamos aqui na empresa. Mas a pior coisa foi saber que ao criar a base através do utilitário aspnet a base de dados vem configurada em modo FULL. Mas o que isso tem haver com o comando SHRINKFILE? Isso é o que irei explicar como dica de hoje :).

Bom continuando sobre a base ASPSTATE e o problema dela está configurada em modo FULL. Nesta configuração significa que qualquer sessão que for criada ou atualizada (transações) será também escrito no log da base de dados e isso é ruim. Ruim por que essa base só serve para armazenar as sessões dos usuários e essa base nunca é consultada a nível de aplicação e esse tempo perdido para também gravar no log é bastante prejudicial a aplicação que muitas vezes tem que ficar aguardando a base ASPSTATE reponder.

Como isso já vem configurado através do utilitário aspnet e o DBA não preste atenção, como foi o meu caso, após alguns dias será percebido que o log da base, no caso ASPSTATE, estará com muitos gigas. Claro que isso acontece também por que não é feito o seu backup (mas para que fazer backup dessa base?).

Analisamos aqui na empresa que o log da base ASPSTATE estava muito alto, algo em torno de 500gb e após configurar a base para modo simples foi utilizado o comando SHRINKFILE que diminuiu o tamanho do arquivo de log para o tamanho informado como parâmetro conforme o exemplo de código abaixo:

DBCC SHRINKFILE (Base_log, 100);

O parâmetro Base_log é o nome do arquivo de log lógico e o segundo parâmetro é o tamanho do arquivo desejável. Na primeira vez que rodamos a base ficou em torno de 100 Gb e após a segunda vez ficou próximo dos 100 Mb informado.

Rodamos o script em um horário comercial e isso não atrapalhou e nem deu queda de performance na aplicação.

Sinceramente estou descontente com esta base de dados do jeito que ela é criada pelo utilitário da Microsoft. Criar em modo FULL é um erro e o JOB de exclusão de sessões expiradas de um em um minuto é outro erro bem grave. Percebemos que a base teve altos deadlocks em transações justamente por causa dessas configurações fazendo com que a aplicação fique muito tempo aguardando para a entrada de um novo usuário que ainda não tem sessão craida. Estudando na internet percebi que alguns consultores em Sql Server altera o JOB para ser executado a cada 5 minutos e assim a base tem um tempo para respirar após deletar os registros expirados.

Espero que tenham gostado de mais essa dica e até a próxima.

Published in.Net FrameworkSQL Server

Be First to Comment

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *