Estratégias de backup no SQL Server 2005

Question

Agradecemos antecipadamente por qualquer ajuda que você possa me oferecer sobre este tópico. Esta é minha primeira postagem de falha de servidor vinda do stackoverflow.

Eu tenho configurado no trabalho uma instância do SQL Server para uma instalação de um aplicativo que vendemos e, idealmente, queremos deixá-lo praticamente por conta própria. Para esse fim, eu configurei vários planos de manutenção que executam backups, limpam tabelas de log e reconstroem índices, etc.

Tudo isso funciona bem, mas estou um pouco confuso sobre a maneira como o backup está funcionando. Eu fui para um backup completo completo soprado semanalmente com backups diferenciais noturnos e backups de log de transações por hora. Tudo estava funcionando bem, mas como o uso do sistema aumentou, percebi que os backups de logs de transações por hora estão ficando enormes. Até e, às vezes, muito além de 2 GB, enquanto o backup completo leva apenas 90 MB. Isso pode ser normal, mas para mim parece estranho. Tanto quanto eu entendi um backup de log de transações é suposto ter um impacto muito pequeno no servidor, mas como pode ser isso, escrevendo 2 GB de dados para fora nunca vai ser tão rápido uma operação. E, claro, o tamanho desses logs está causando problemas de espaço em disco (a especificação do servidor é mesquinha - não minha escolha) e tivemos alguma perda de serviço.

Então, duas perguntas realmente, por que os backups de log de transações são tão grandes, e provavelmente estou fazendo algo errado.

Em segundo lugar, devo me preocupar com backups de log de transações, porque não apenas ir para backups diferenciais por hora, como eles são apenas cerca de 20MB de tamanho.

Se alguém gosta de me apontar na direção de uma boa leitura sobre o assunto de backups eu também gostaria disso. Eu tenho um bom livro, SQL Server 2005 liberado, mas eu provavelmente preciso de um livro mais detalhes sobre backup para realmente obter as informações que eu preciso para projetar um plano de backup apropriado.

    

Answer 1

Um dos motivos que causa esse comportamento é quando você tem um banco de dados realizando muitas atualizações, inserções & exclui. No seu caso, o banco de dados geral pode não aumentar de tamanho se os dados estiverem sendo atualizados ou se as linhas estiverem sendo inseridas / excluídas. Ter seu banco de dados em Modelo de Recuperação Completa significa que o SQL Server precisa manter um registro em execução de todas essas mudanças, que é o que permite executar a recuperação pontual, mas, consequentemente, significa seu log. os backups serão grandes.

Primeiramente, eu questionaria se o seu aplicativo realmente precisa de recuperação pontual? Não que isso seja uma decisão que você possa tomar, é uma decisão de negócios. Se a empresa decidir que precisa de um ponto no tempo, considere fazer backups de log de transação em intervalos menores & deixe os poderes saberem que você vai precisar de muito armazenamento!

Se a empresa decidir que não precisa de tempo point-int, mas quer uma capacidade de recuperação atualizada, considere usar o Bulk-logged Recovery Model e fazer backups de log em intervalos de alguns minutos. Isso pode reduzir o tamanho de seus backups de log, dependendo do que o aplicativo está fazendo, pois determinadas operações podem ser minimamente logado . Isso significa que, quando ocorre um backup de log, ele está realmente copiando as páginas de dados de transações minimamente registradas.

É claro que, se a empresa estiver satisfeita em perder algumas horas de dados ou valer um dia, mudar para Simple Recovery Model com uma combinação de backups completos / diferenciais é o caminho a ser seguido.