Manutenção do log de transações ao alternar para a recuperação simples

Fundo:

Recentemente, herdei mais de 50 servidores SQL com mais de 450 bancos de dados. Os backups noturnos têm aproximadamente 8 TB e, escusado será dizer, estamos usando mais espaço em disco do que gostaríamos. Todos os bancos de dados estão definidos para recuperação total e os logs de transações nunca foram copiados. Passei por todos os servidores SQL e identifiquei os de baixa prioridade que precisam apenas de um backup noturno e onde um dia de perda de dados seja aceitável.

Questão:

Estou mudando muitos bancos de dados de baixa prioridade para o SIMPLEmodo de recuperação FULL. Os logs de transações existentes serão truncados (quando os pontos de verificação forem criados)? Alguns dos logs de transações existentes são de 50 a 100 GB; qual é a melhor abordagem para determinar com o que devo reduzi-los para os propósitos de avançar? Eu obviamente não quero mantê-los tão grandes. Ou eles vão diminuir por conta própria com o tempo (acho que não)?

Antes de FULLpassar para o SIMPLEmodelo de recuperação, pergunte a si mesmo quantos dados você pode perder. Para os bancos de dados em que, em caso de desastre, você pode restaurar o último backup do banco de dados, tudo SIMPLEbem. Se não for esse o caso, fique com FULL.

Para reduzir o LDFarquivo ao menor tamanho possível, siga as etapas fornecidas por Kimberly Tripp aqui: 8 etapas para melhorar a taxa de transferência do log de transações

1. Aguarde o tempo em que há pouca atividade no banco de dados

2. Execute no SSMS:

   DBCC SHRINKFILE(transaction_log_logical_filename, TRUNCATEONLY)

3. Modifique o tamanho do arquivo do log de transações:

   ALTER DATABASE db_name
   MODIFY FILE ( NAME = transaction_log_logical_filename, SIZE = new_size)
   

Estou mudando muitos bancos de dados para o modo de recuperação SIMPLES do modo de recuperação COMPLETO (registros T e recuperação pontual não são necessários). Os logs de transações existentes serão truncados (quando os pontos de verificação forem criados)?

No modelo de recuperação simples, o mecanismo do banco de dados emitirá pontos de verificação automáticos e sua frequência é determinada pelo intervalo de recuperação (configuração avançada da configuração do servidor) ou se o log ficar 70% cheio.

A menos que você tenha algumas transações de longa duração que atrasarão o truncamento do log, um ponto de verificação automático truncará a parte não utilizada do T-log.

Alguns dos logs de transações existentes são de 50 a 100 GB, qual é a melhor abordagem para determinar com o que devo reduzi-los para os propósitos de avançar. Eu obviamente não quero mantê-los tão grandes.

Se você tiver o modelo de recuperação de banco de dados definido como COMPLETO para os bancos de dados com 50 a 100 GB de logs em T, será necessário começar a fazer backups frequentes do log em T. Lembre-se de que no modelo de recuperação completa, uma vez estabelecida a cadeia de backup de log, mesmo os pontos de verificação automáticos não farão com que o log seja truncado.

Como último recurso, você pode truncar o arquivo de log e fazer imediatamente um backup completo e começar a fazer backups do T-log para que você possa fazer a recuperação pontual se ocorrer um desastre.

Ou eles vão diminuir por conta própria com o tempo (acho que não)?

Como o @TomTom apontou, é uma operação manual.

Leia :

• Gerenciar o tamanho do arquivo de log de transações
• COMO ATRIBUIR O LOG DO SERVIDOR SQL - Excelente gravação.
• Como funcionam os pontos de verificação e o que é registrado ? Por: Paul Randal

Muitas das perguntas não podem ser respondidas por nós. Quanto tempo dura um pedaço de barbante?

Alguns dos logs de transações existentes são de 50 a 100 GB, qual é a melhor abordagem para determinar com o que devo reduzi-los para os propósitos de avançar.

Contanto que eles precisam ser. Eu sugiro NÃO encolher. Trunacate logs, volte em uma semana e veja quanto espaço é usado, ENTÃO decida. Mas você tem que responder a esta.

Os backups noturnos têm aproximadamente 8 TB e é desnecessário dizer que estamos usando mais espaço em disco do que gostaríamos.

Então, por que transformá-los em simples? Quero dizer, sério.

Todos os bancos de dados estão definidos para recuperação total e os logs de transações nunca foram copiados.

Um pouco de lógica dirá que, se você os truncar UMA VEZ, provavelmente usará MUITO menos espaço para fazer backup deles de qualquer maneira. O resultado pode ser que você pode mantê-los no modo de recuperação total. Experimente isso primeiro. Se eles tiverem um volume baixo, etc., os backups de log serão MUITO menores no futuro.

Passei por todos os servidores SQL e identifiquei os de baixa prioridade que precisam apenas de um backup noturno e dias de perda de dados mesmo em um desastre não será um problema (bancos de dados de fax e coisas assim).

Sim. Isso é até você terminar no tribunal e ser julgado por não ter documentos legais críticos. Você sabia que os registros de fax podem fazer parte do que você deve manter por anos como informações relevantes para os negócios? É assim na minha jurisdição (10 anos). Se você é uma empresa de ações em U, pode haver uma surpresa semelhante (SOX). Não fazer isso MUITO ruim no tribunal, se você quiser provar que não recebeu um fax. Ou enviou um. Ninguém se importa se isso aconteceu mensalmente e você tem registros mais recentes - você não cumpre os requisitos da lei. Certifique-se de que isso seja assinado por alguém MUITO alto, porque seus negócios não críticos podem ser seu motivo de demissão.

Ou eles vão diminuir por conta própria com o tempo (acho que não)?

Não. E eles não deveriam fazer isso. O redimensionamento de log é uma operação manual, exceto para bancos de dados de baixo volume.