Log de transações: Truncar x backup

Question

Eu tenho uma instância SAP ECC que é executada no SQL Server 2000. O banco de dados é configurado com o modelo de recuperação Completa, mas um backup de log de transação é nunca concluído (não é minha escolha). Em vez disso, um backup completo é salvo diariamente.

Isto, obviamente, implica que o arquivo de log de transações continua crescendo. Para controlar seu tamanho, uma vez por mês, o log de transações é truncado e, em seguida, reduzido com dbcc shrinkfile (novamente, não é minha escolha).

Como você pode adivinhar facilmente, isso não funciona muito bem porque às vezes o arquivo de log cresce muito rápido, preenche sua partição e o banco de dados é interrompido. Fui convidado para melhorar esta situação.

Se a escolha fosse minha, faria um backup do log de transações várias vezes por dia, mas a pessoa realmente responsável não quer isso.

A segunda escolha óbvia seria executar o truncado & encolher o emprego com mais frequência. Mas pelo que entendi não é uma boa escolha. Uma coisa que eu li aqui me preocupa mais:

by truncating the log at (time), you've just completely invalidated the consistency of your log and there's NO way to recover ANY data past (time of the last full backup).

Isso é verdade? Isso significa que o arquivo de log em uso agora é completamente inútil? Se eu começasse a fazer o backup regularmente agora, ele se tornaria utilizável para uma recuperação point-in-time? Os backups de log seriam consistentes? É melhor eu usar o modelo de recuperação simples?

Obrigado.

    

Answer 1

Isso é basicamente correto, se você truncar o log, então qualquer backup de log que você tentar fazer depois será totalmente inútil (não sei se o SQL Server permitirá que você faça um backup de log depois disso - pode muito bem não, simplesmente porque seria inútil). Você precisa fazer outro backup completo ou diferencial para reiniciar a cadeia de logs, e nesse ponto você pode começar a fazer backups de log novamente.

E mesmo que você nunca faça backup do registro, ele ainda pode ser útil. Se o volume que hospeda o arquivo de dados for interrompido, você poderá executar um backup de log do log (supostamente grande) e usar esse mesmo backup após restaurar o backup completo com NORECOVERY e ter pouca ou nenhuma perda de dados. No entanto, se o volume que hospeda o arquivo de log for interrompido, você será principalmente operado sem backups de log.

Dadas as restrições que você especificou (ou seja, nenhum backup de log regular), eu continuaria com sua abordagem atual, mas certifique-se de que um backup completo seja executado imediatamente após o truncamento. Ainda é uma maneira ruim de operar, mas é mais seguro do que usar recuperação simples ou truncamentos de log mais frequentes sem backups completos depois.

Mas se você conseguir convencer os caras responsáveis, até mesmo um backup diário de log seria uma grande melhoria. Talvez agendá-lo para acontecer imediatamente antes do backup completo.

    

Answer 2

É melhor usar um modelo de recuperação simples. um arquivo de log que não tenha backup não é útil de qualquer maneira. APENAS backups podem ser restaurados. Então, se você não fizer backup, qual é o log?

Quem quer que tenha declarado que não deve trabalhar em TI, mas isso não é seu pribme. Quando algo parece, sua empresa é história.