Como reduzo o tamanho do backup do log de transações após um backup completo?

38

Eu tenho três planos de manutenção configurados para execução em uma instância do Sql Server 2005:

  • Otimizações semanais do banco de dados, seguidas por um backup completo
  • Backup diferencial diário
  • Backups de log de transações por hora

Os backups de log por hora geralmente variam entre algumas centenas de Kb e 10 Mb, dependendo do nível de atividade, os diferenciais diários geralmente aumentam para cerca de 250 Mb até o final da semana e o backup semanal é de cerca de 3,5 GB.

O problema que tenho é que as otimizações antes do backup completo parecem estar fazendo com que o próximo backup do log de transações aumente para mais do dobro do tamanho do backup completo, neste caso 8 GB, antes de retornar ao normal.

Além disso BACKUP LOG <DatabaseName> WITH TRUNCATE_ONLY, existe alguma maneira de reduzir o tamanho desse backup de log ou impedir que as otimizações sejam registradas no log de transações, pois certamente elas serão contabilizadas no backup completo que precedem?

Dave
fonte
1
Marcou com +1 por causa da troca de idéias produzida por esta pergunta.
MarlonRibunal 27/05

Respostas:

35

Algumas sugestões interessantes aqui, que parecem mostrar um mal-entendido sobre como os backups de log funcionam. Um backup de log contém TODOS os logs de transações gerados desde o backup de log anterior, independentemente de quais backups completos ou diferenciais são executados nesse ínterim. A interrupção dos backups de log ou a migração para backups completos diários não terão efeito nos tamanhos dos backups de log. A única coisa que afeta o log de transações é um backup de log, depois que a cadeia de backup de log é iniciada.

A única exceção a essa regra é se a cadeia de backup de log foi quebrada (por exemplo, acessando o modelo de recuperação SIMPLE, revertendo a partir de uma captura instantânea de banco de dados, truncando o log usando BACKUP LOG WITH NO_LOG / TRUNCATE_ONLY); nesse caso, o primeiro backup de log conterá todo o log de transações desde o último backup completo - que reinicia a cadeia de backup de log; ou se a cadeia de backup de log não tiver sido iniciada - quando você alterna para COMPLETO pela primeira vez, você opera em um tipo de modelo de recuperação pseudo-SIMPLES até que o primeiro backup completo seja realizado.

Para responder à sua pergunta original, sem entrar no modelo de recuperação SIMPLE, você precisará fazer backup de todo o log de transações. Dependendo das ações que você está realizando, você pode fazer backups de log mais frequentes para reduzir seu tamanho ou fazer um banco de dados mais direcionado.

Se você puder postar algumas informações sobre as operações de manutenção que você está fazendo, eu posso ajudá-lo a otimizá-las. Você está, por acaso, fazendo reconstruções de índice seguidas por um banco de dados reduzido para recuperar o espaço usado pelas reconstruções de índice?

Se você não tiver nenhuma outra atividade no banco de dados enquanto a manutenção estiver ocorrendo, faça o seguinte:

  • verifique se a atividade do usuário está parada
  • faça um backup final do log (isso permite recuperar até o ponto de início da manutenção)
    • mude para o modelo de recuperação SIMPLES
    • executar manutenção - o log será truncado em cada ponto de verificação
    • alterne para o modelo de recuperação COMPLETO e faça um backup completo
    • continue como normal

Espero que isso ajude - ansioso por mais informações.

obrigado

[Editar: depois de toda a discussão sobre se um backup completo pode alterar o tamanho de um backup de log subsequente (não pode), montei uma postagem abrangente no blog com material de fundo e um script que comprova isso. Confira em https://www.sqlskills.com/blogs/paul/misconceptions-around-the-log-and-log-backups-how-to-convince-yourself/]

Paul Randal
fonte
4
Paul - discordo totalmente. Apenas não faça backups de log durante a manutenção do índice. O log aumentará e o próximo backup completo será maior, mas você não terá o desempenho atingido pelos backups de t-log que ocorrem ao mesmo tempo que os trabalhos de manutenção de índice. Você pode ver o mérito disso? Certamente você concorda que backups simultâneos do t-log e manutenção do índice causariam um impacto no desempenho.
Brent Ozar
6
Não - eu ainda discordo. Eu prefiro ter backups de log mais frequentes para que eles sejam menores, em vez de um monstro depois de toda a manutenção. Ter backups de log de tamanho desproporcional pode causar problemas para copiá-los pela rede (por exemplo, para backups externos ou envio de logs). Se não houver atividade do usuário e nenhuma outra necessidade de backups de log, talvez , mas se o sistema travar e você precisar fazer um backup completo, isso levará muito tempo e faz parte do seu tempo de inatividade . Eu deveria fazer um post sobre isso.
Paul Randal
E mesmo isso não ajuda a questão original do OP de como reduzir o tamanho do backup de log após a manutenção do índice - na verdade, ele potencialmente aumentará, dependendo de quais operações estão sendo realizadas.
Paul Randal
5

Você pode reduzi-los, mas eles apenas crescerão novamente, eventualmente causando fragmentação do disco. As recriações e desfragmentações de índice criam logs de transações muito grandes. Se você não precisar de capacidade de recuperação point-in-time, poderá mudar para o modo de recuperação Simples e eliminar completamente os backups do log de transações.

Suponho que você esteja usando um plano de manutenção para as otimizações. Você pode alterá-lo para usar um script que desfragmenta o índice somente quando um certo nível de fragmentação é atingido e você provavelmente não sofrerá nenhum impacto no desempenho. Isso geraria logs muito menores.

Eu ignoraria os diferenciais diários em favor dos backups completos diários BTW.

SqlACID
fonte
Suponho que eu poderia fazer um TRUNCATE LOG direto no final do backup completo, mas esse não parece exatamente o melhor método, eu esperava algumas alternativas ... Quais seriam os benefícios de fazer backups completos diários do que diffs? Isso parece usar mais espaço para relativamente pouco benefício. Também não posso mudar para uma recuperação simples, pois preciso do nível de granularidade que os backups de log por hora fornecem. Por fim, não tenho certeza de como a otimização de um script ajudaria, certamente ainda teria o mesmo problema com menos frequência?
315 de Dave
Eu diminuí a votação por causa da sugestão de pular diferenças e ir para as diárias cheias. Por quê? Cheia a 3,5 GB, enquanto as diferenças são apenas 250 MB. A estratégia de backup parece absolutamente boa para mim. Remover diffs significa muitos GBs a mais de armazenamento, com apenas uma pequena aceleração no tempo de restauração.
2113 Paul Randal
2
A situação de todos é diferente, não há nada errado com as diferenças, mas, a menos que o espaço seja escasso, se você precisar se recuperar rapidamente, é melhor dar um passo do que dois.
SqlACID
1
@Dave Veja a resposta de Jeremy, crie um procedimento armazenado para desfragmentar arquivos específicos, divida-os em pedaços menores.
SqlACID
3

Sua pergunta final foi: "Além de BACKUP LOG WITH TRUNCATE_ONLY, existe alguma maneira de reduzir o tamanho desse backup de log ou impedir que as otimizações sejam registradas no log de transações, pois elas certamente serão contabilizadas na íntegra backup eles precedem? "

Não, mas aqui está uma solução alternativa. Se você souber que as únicas atividades nesse banco de dados naquele momento serão os trabalhos de manutenção de índice, poderá parar os backups do log de transações antes que a manutenção do índice seja iniciada. Por exemplo, alguns dos meus servidores nas noites de sábado, os horários de trabalho são assim:

  • 21:30 - o backup do log de transações é executado.
  • 21:45 - o backup do log de transações é executado pela última vez. A programação é encerrada às 9:59.
  • 22:00 - o trabalho de manutenção de índice é iniciado e possui paradas internas para concluir antes das 11:30.
  • 23:30 - o trabalho de backup completo inicia e termina em menos de 30 minutos.
  • 12:00 - os backups do log de transações são iniciados novamente a cada 15 minutos.

Isso significa que não tenho capacidade de recuperação pontual entre 21h45 e 23h30, mas o resultado é um desempenho mais rápido.

Brent Ozar
fonte
E você deve mudar para SIMPLES antes das 22h, certo? Caso contrário, o backup do log das 12h conterá todo o log gerado entre 22h e 00h.
2113 Paul Randal
Ops, esqueci de mencionar que eu diminuí a votação também, porque você não mencionou estar no SIMPLE. Ficar em BULK_LOGGED mesmo não alterará o tamanho do próximo backup de log, pois captará todas as extensões de dados alteradas pelas operações com registro mínimo. Wow - diminuiu a votação de todas as respostas até agora.
Paul Randal
NÃO , definitivamente não mude para o simples. Ele perguntou sobre o tamanho dos backups do log de transações, não o tamanho dos backups completos ou do arquivo de log de transações.
Brent Ozar
Então, como o que você faz reduz o tamanho dos backups do log de transações? Eles conterão tudo desde o backup de log anterior, a menos que você esteja quebrando a cadeia de backup de log e depois reiniciando-o com o backup completo.
Paul Randal
A menos que seu trabalho de manutenção do índice não faz nada ...
Paul Randal
3

Resposta fácil: altere seu trabalho de otimização semanal para executar de maneira mais equilibrada todas as noites. ou seja, re-indexar as tabelas ae no domingo à noite, f-l na segunda-feira à noite etc ... encontre um bom equilíbrio, seu log será aproximadamente 1/6 do tamanho médio. É claro que isso funciona melhor se você não estiver usando o trabalho de manutenção de índice ssis interno.

A desvantagem disso é significativa, dependendo da carga que o seu banco de dados experimenta, é que causa estragos no otimizador e na reutilização dos planos de consulta.

Mas se tudo o que importa é o tamanho do seu t-log semanalmente, divida-o de um dia para o outro ou de hora em hora e execute os backups do t-log no meio.


fonte
2

Você também pode procurar uma ferramenta de terceiros (Litespeed da Quest, SQL Backup da Red Gate, Hyperbac) para reduzir o tamanho dos backups e logs. Eles podem se pagar rapidamente com economia de fita.

Steve Jones
fonte
2

Provavelmente, pode-se supor que suas "otimizações" incluem recriações de índice. Somente a execução semanal dessas tarefas pode ser aceitável em um banco de dados que não encontra muitas atualizações e inserções; no entanto, se seus dados forem altamente fluidos, convém fazer algumas coisas:

  1. Reconstrua ou reorganize seus índices todas as noites, se sua agenda permitir e se o impacto for aceitável. Ao executar essas tarefas noturnas de manutenção de índice, direcione-se apenas aos índices fragmentados além de, digamos, 30% para reconstruções e na faixa de 15 a 30% para reorganizações.

  2. Essas tarefas são transações registradas; portanto, se você estiver preocupado com o crescimento de logs, eu recomendaria o que Paulo recomendou. O backup final do log de transações antes da manutenção do índice, alterne para Recuperação simples, seguido pelo processo de manutenção e, em seguida, volte para Recuperação total seguida por um backup completo de dados.

Adoto uma abordagem zen para meus arquivos de log: eles são do tamanho que eles querem ter. Contanto que eles não tenham suportado um crescimento aberrante devido a práticas inadequadas de backup em comparação com a atividade do banco de dados, esse é o mantra que eu vivo.

Quanto aos scripts que executam a manutenção de índice discricionária, ficam on-line: há muito por aí. Andrew Kelly publicou um artigo decente na SQL Magazine cerca de um ano atrás. O SQLServerPedia possui alguns scripts de Michelle Ufford, e a última edição da SQL Magazine (julho de 2009, acredito) também possui um artigo completo sobre o assunto. O objetivo é encontrar um que funcione bem para você e torná-lo seu com personalizações mínimas.

Tim Ford
fonte
2

Você pode fazer backup especialmente do seu log de transações em vários pontos durante a otimização do banco de dados? O tamanho total dos logs t seria o mesmo, mas cada um seria menor, possivelmente ajudando você de alguma forma.

Você pode fazer uma otimização mais direcionada do banco de dados para criar menos transações (alguém mencionou isso, mas não tenho certeza de que as implicações foram explicadas). Como tolerar uma certa quantidade de fragmentação ou espaço desperdiçado por um tempo. Se 40% das suas tabelas estiverem fragmentadas em apenas 5%, não tocá-las poderia economizar um pouco de atividade.

ErikE
fonte