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:

• Parte 1: O básico
• Parte 2: Dicas e Casos
• Parte 3: Na prática (será publicado em 19.01.15)

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.

/******

Autor: Renato Siqueira (@radrenato)
Descrição: Realiza Cycle no ERRORLOG sob duas condições:
1) Se o arquivo atual for maior que determinado limite estabelecido 
2) Se for determinado dia da semana, no caso fictício do script, no sábado.


*****/



/* Variável de tabela responsável por receber o tamanho dos arquivos atuais de errorlog */

	DECLARE @TamanhoMaximoMB SMALLINT = 250

	DECLARE @vErrorlogs AS TABLE
	(
			Archives TINYINT,
			[Date] DATETIME,
			[Log File Size (Bytes)] BIGINT
	)

	SET NOCOUNT ON
 
	BEGIN  

	/* A ideia aqui é, embora capture o tamanho de todos, analisar apenas o errorlog atual */

	INSERT INTO @vErrorlogs (Archives,Date, [Log File Size (Bytes)])
	EXEC XP_ENUMERRORLOGS

	/* Verifica tamanho do log atual */

	DECLARE @TamanhoLogAtual BIGINT = (SELECT ([Log File Size (Bytes)]/1024)/1024 FROM @vErrorlogs E WHERE E.Archives = 0)
		
	/* Verifica se o tamanho do errorlog atual passa do nosso tamanho máximo indicado na variável @TamanhoMaximoMB */
	
	IF   @TamanhoLogAtual > (1048576*@TamanhoMaximoMB)
	BEGIN  
				PRINT 'ERRORLOG maior que o threshold escolhido'+CAST(@TamanhoMaximoMB AS VARCHAR(4))+'. Reciclando...';
				EXEC SP_CYCLE_ERRORLOG;
	END	 

	/* Recicla em determinado dia da semana. Em nosso caso, no sábado  */

	IF DATENAME(weekday,GETDATE()) = 'Saturday'
	BEGIN		
			PRINT 'Reciclando o errorlog: Cycle semanal.';
			EXEC sp_cycle_errorlog;		
	END

	ELSE
	
			BEGIN		
				 PRINT 'Não há necessidade de Recycle. O tamanho máximo é de  '+CAST(@TamanhoMaximoMB as varchar(50))+' MB e o tamanho atual do arquivo é de '+CAST(@TamanhoLogAtual AS VARCHAR(50))+' MB.'
			END

END

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