Como a redução de um arquivo de log do SQL Server afeta o desempenho?

Eu tenho um banco de dados do SQL Server 2008 que possui um arquivo de dados com tamanho de 2 GB, mas o arquivo de log tem mais de 8 GB. Nos bancos de dados anteriores a 2008, eu poderia usar o 'Log de backup' e a TRUNCATE_ONLYopção, mas isso não está mais disponível nos bancos de dados de 2008 e posteriores.

Eu tenho um script que trunca o arquivo de log:

USE [MyDatabase]
GO
ALTER DATABASE [MyDatabase] SET RECOVERY SIMPLE WITH NO_WAIT
DBCC shrinkfile('MyDatabase_log', 1)
ALTER DATABASE [MyDatabase] SET RECOVERY FULL WITH NO_WAIT
GO

Isso trunca o arquivo de log completamente, mas minha pergunta é: isso afeta o desempenho?

Eu executo dois backups completos diariamente, para que o log não seja realmente necessário no que diz respeito à rolagem de dados.

Eu realmente recomendo a leitura de Importância do gerenciamento adequado do tamanho do log de transações por Paul S. Randal.

A quintessência é que existem apenas duas maneiras realmente boas de lidar com o log de transações :

1. Faça backups regulares do arquivo LOG e o arquivo LOG reutilizará seu espaço após cada backup LOG e não aumentará indefinidamente, ou

2. Use o modelo de recuperação SIMPLE e você não precisa se preocupar com o tamanho do arquivo LOG, como faz backups completos regulares.

O que diz respeito ao truncamento e desempenho do arquivo LOG é que você sempre terá um impacto no desempenho quando o arquivo LOG for aumentado (uma citação da postagem do blog acima):

Se você reduzir o log, ele aumentará novamente - possivelmente causando a fragmentação do VLF e definitivamente causando uma pausa na carga de trabalho enquanto o log aumenta, pois o log não pode usar a inicialização instantânea [...]

Atualização: Não confunda o truncamento do arquivo LOG com o arquivo DATA. O encolhimento do arquivo DATA é muito ruim. Consulte Por que você não deve reduzir seus arquivos de dados para obter detalhes.

OK primeiro, sim, o log é necessário, mesmo com os backups completos diários, se você desejar recuperar novamente em caso de um problema. Fazemos backup do nosso log de transações a cada 15 minutos. O problema é que você não está fazendo backup do seu log de transações e é por isso que o log cresce tão absurdamente. Você quase nunca precisará reduzir um log de transações se estiver fazendo backups corretos do log de transações.

Você precisará fazer backup do banco de dados antes de truncar o log. Sugiro fazê-lo fora do horário comercial, para que nenhum novo dado seja inserido entre o backup e o truncamento. Em seguida, configure backups de log de transações adequados para que você nunca tenha esse problema novamente.

Quanto a afetar o desempenho, bem, sem conhecer os detalhes do hardware e do uso do sistema, seria difícil dizer.

Com que rapidez o log de transações cresce? Se for bastante rápido, você afetará o desempenho reduzindo-o para quase nada, pois ele precisa gastar tempo para recuperá-lo. Isso não significa que você não deve encolhê-lo de vez em quando, mas você deve pensar no problema do tamanho, em vez de apenas encolher o mínimo. O perf é enorme? Provavelmente não, mas depende da carga no servidor (número de transações, etc.).

Uma coisa que considero problemática é "Eu executo 2 backups completos diariamente, para que o log não seja realmente necessário no que diz respeito à transferência de dados". O log é extremamente importante para pontos entre seus backups completos. Mesmo duas vezes por dia não elimina a necessidade de um arquivo de log para recuperação de desastres, a menos que este seja um banco de dados somente leitura (se fosse, você não veria o grande aumento no arquivo de log).