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?
Respostas:
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:
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/]
fonte
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.
fonte
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:
Isso significa que não tenho capacidade de recuperação pontual entre 21h45 e 23h30, mas o resultado é um desempenho mais rápido.
fonte
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
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.
fonte
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:
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.
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.
fonte
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.
fonte