Resumo: Se você se encontrar nessa situação, provavelmente desejará a Opção 1 abaixo. Pule para corrigir o problema ou continue lendo para mais explicações.
Um banco de dados no Microsoft SQL Server tem diferentes "modos de recuperação" nos quais pode ser configurado:
-
Simples. Você pode fazer backups completos e backups diferenciais de um banco de dados no modo de recuperação simples. Um backup completo contém o banco de dados inteiro em um determinado momento, enquanto um backup diferencial contém tudo o que foi alterado desde o último backup completo.
Um plano de backup para esse banco de dados pode ser "Um backup completo todo domingo, além de um backup diferencial diário". Isso mantém os backups diferenciais relativamente pequenos, já que eles contêm apenas dados alterados desde o domingo anterior. No caso de uma falha, você não perde mais de 1 dia de dados.
-
Completo. Você ainda pode fazer backups completos e diferenciais, mas também deve fazer backups periódicos do log de transações. Enquanto os backups diferenciais contêm alterações no banco de dados desde o último backup completo, os backups de log contêm apenas dados desde o último backup de log , portanto, os backups de log devem ser pequenos e rápidos.
Um plano de backup para um banco de dados de recuperação completo pode ser "um backup completo semanal, um backup diferencial diário e um backup de log de transação a cada 5 minutos". Isso significa que você nunca perderá mais de 5 minutos de dados. Ao restaurar esse banco de dados, você restauraria para o backup diferencial mais recente e aplicaria todos os backups de log feitos desde aquele ponto.
-
Em massa registrado. Isso é como "modo de recuperação total, exceto quando eu disser o contrário".
A recuperação total é ótima porque você pode restaurar seu banco de dados quase até o momento de uma falha, mas também é necessário fazer backups de log. Por quê? Porque os logs dentro do arquivo de log de transações são marcados como "truncados" apenas depois que você faz um backup de log. Depois que um log é truncado, novos logs podem sobrescrevê-lo.
Se você nunca fizer um backup de log, nada no log de transações será marcado como truncado e, portanto, o arquivo de log deverá crescer com cada alteração no banco de dados.
Para mais informações sobre como o log de transações funciona, leia os excelentes artigos de Paul Randal:
Agora, na situação em que você se encontra com um enorme log de transações, há duas opções reais:
Opção 1: alterne para o modelo de recuperação simples
Você provavelmente não precisa fazer backups de log (já que não está fazendo isso agora), portanto, basta alternar para o modelo de recuperação simples:
ALTER DATABASE [MyDatabase] SET RECOVERY SIMPLE
Isso marcará tudo no log de transações como truncado, para que o arquivo de log não seja maior. Depois de fazer isso, reduza o arquivo de log físico:
DBCC SHRINKFILE N'MyDatabase.ldf'
Isso significa que o arquivo de log será truncado automaticamente após cada transação. Portanto, seu tamanho não ficará fora de controle. Você provavelmente não precisará gerenciar o log de transações; no entanto, você perde a capacidade de restaurar seu banco de dados além do último backup completo ou diferencial.
Opção 2: começar a fazer backups de log de transação
Se você realmente precisa de recuperação completa, você deve começar a fazer backups de log de transações.
Primeiro, para sair da situação ruim, você quer truncar o log inteiro e encolher:
BACKUP LOG [MyDatabase] WITH TRUNCATE_ONLY
GO
DBCC SHRINKFILE N'MyDatabase.ldf'
GO
Agora, seu arquivo de log de transações deve ter um tamanho razoável. Ela começará a crescer novamente de imediato; Apesar. Agora você deve começar a fazer backups de log regularmente. Você pode fazer isso através de um plano de manutenção ou através da execução regular de um comando como:
BACKUP LOG [MyDatabase] TO DISK = N'C:\Backups\MyDatabase_Log_Backup1.bak' WITH INIT
Nota lateral
DBCC SHRINKFILE não deve ser usado regularmente:
- Os arquivos de log crescerão de volta para um tamanho estável com base na atividade do banco de dados e com que frequência você faz backups de log.
- A redução de arquivos de dados fragmenta completamente seus índices.
Se você estiver reduzindo os arquivos de log regularmente, provavelmente deverá alternar para o modelo de recuperação simples ou fazer backups de log mais frequentes.