Eu tenho vários bancos de dados do SQL Server 2008 com logs de transações que ficaram fora de controle e encheram a unidade. Um desses logs era de 68 gb caramba .
Eu sei que não devo matar minha cadeia de backup truncando o log, mas quando eu faço um encolhimento sozinho, em vários dos bancos de dados não recebo nenhuma recuperação de espaço e naqueles que faço, a quantidade é insignificante. Eu verifiquei que o cliente está executando backups t-log de hora em hora e que eles foram bem-sucedidos nas últimas semanas.
Obviamente eu estou perdendo alguma coisa. Alguém pode me indicar a direção certa ou estou preso em ter que truncar manualmente e rezar para que nada aconteça nesse meio tempo?
Essa é uma daquelas exceções em que provavelmente não há problema em executar um arquivo
DBCC SHRINKFILE
. O arquivo de log provavelmente é tão grande, não por causa do que está acontecendo agora, mas porque houve um tempo em que os logs de transação por hora não estavam sendo executados (ou você teve uma transação excepcionalmente grande que foi executada entre ou entre os backups de log). Não tenho certeza de onde vem o equívoco, mas fazer backup do log não reduz o arquivo para você, apenas libera espaço dentro do arquivo.Você pode executar uma operação única como esta sem interferir na cadeia de log (ou ter que "esperar" que "nada aconteça nesse meio tempo"), de preferência logo após a conclusão bem-sucedida de um backup de log:
Isso deve reduzir o arquivo para aproximadamente 4 GB, o que, com sorte, é bastante espaço para acomodar suas transações de hora em hora. Você pode querer escolher um tamanho diferente, não tenho certeza...
Se este comando não reduzir o arquivo tanto quanto você espera, você pode verificar por que a modificação do log pode ser bloqueada usando: