Controlando o crescimento do ERRORLOG

Finge que é o errorlog =p

Olá,

Recentemente comecei uma pequena série sobre ERRORLOG composta de três partes. Antes de prosseguir com o post de hoje que é um extra ao assunto, apresento os posts da série caso tenha interesse:

Sendo direto ao ponto: Ter um ERRORLOG grande não é algo comumente desejado, por vários motivos:

  • Demora ao abrir o arquivo: É frustante abrir arquivos grandes principalmente quando queremos uma resposta rápida e experimentamos lentidão.
  • Dificulta manipulação do arquivo: Para esta finalidade, queremos arquivos de fácil manipulação e o tamanho é um dos fatores cruciais pra essa condição.
  • Evita estouro em disco: Em geral não é algo a se preocupar, pois depende do ambiente. Mas imagine que você não precise manter o errorlog no C:  com pouco espaço e as bases de sistema também estão neste disco. Caso mudar o local não seja possível  (cenários e cenários…) você precisa se certificar que um arquivo de errorlog não seja o responsável pela parada de uma instância inteira comprometendo o disco e prejudicando por exemplo, o tempdb.

Dito isso, tenho a opinião de que é interessante controlar o crescimento dos logs aqui citados. Existe uma solução pouco conhecida (e citada aqui pelo Paul Randal) que automaticamente dispara um recycle quando determinado threshold é alcançado mas funciona apenas no SQL Server 2012 ou superior (build à consultar…)  realizando algumas alterações no registro.

É possível confeccionar uma solução destas no SQL Serer 2008 R2? Sim, e vai de cada cenário e necessidade… Sugiro aqui uma solução não-reativa: um script que pode (idealmente) ser agendado via SQL Server Agent e rodado diariamente, podendo fazer o recycle ou não sob determinadas condições. Destaco que a solução abaixo atende bem um cenário X mas não necessariamente Z ou Y, já que existem N formas de endereçar uma solução para o assunto.

Você implementa(ou) alguma solução parecida no seu ambiente ou outra bem diferente? Alguma opinião sobre o assunto? Sinta-se à vontade para postar.


Semana que vem fecho a série de ERRORLOG e prometo mais posts voltados para infra, mas de uma forma um pouco diferente, fugindo do convencional.

[]’s

Leave a Comment

Your email address will not be published. Required fields are marked *