Quebrando cadeia de log de transações com backups

Question

Eu fui indicado para manter um SQL Server com o envio de log nele. Uma vez por semana, os índices são recriados e, em seguida, é feito um backup. Na semana passada, o plano de manutenção que recria os índices não foi executado corretamente e, portanto, o backup não ocorreu. O próximo log de transações foi 4x maior do que o backup teria sido, preenchido todo o espaço restante no servidor e jogou todo o nosso log shipping fora do curso por um dia.

Examinando os logs de transação em mais detalhes (sou um desenvolvedor, não um DBA), descobri que estava errado ao acreditar que o backup impediu que o log de transações ficasse enorme após a reconstrução do índice. O que acabou por ser foi um script SQL no final do plano de manutenção que simplifica o modo de recuperação do banco de dados, encolhe e, em seguida, o altera de volta para completo.

Estou correto em assumir que isso quebra a cadeia do log de transações e faz com que o primeiro backup completo depois disso inicie os logs de transação de si mesmo - e que qualquer backup de banco de dados durante a semana possa ser ignorado em favor de apenas aplicando logs de transação a este backup semanal?

    

Answer 1

Você está correto, alterando o nível de log para simples e vice-versa invalida a cadeia de log que exige que um backup completo seja feito.

Você deve remover essa opção e o comando de redução de arquivo de log. Basta fazer o backup do log e fazer com que as alterações de log sejam aplicadas ao servidor de destino de envio de logs.

Sempre que você alterar o modelo de recuperação do banco de dados de completo para simples e voltar, a operação de remessa de logs terá que ser iniciada novamente, restaurando o backup completo. Se você não alterar o modelo de recuperação, nunca precisará restaurar o backup completo para o servidor de destino depois da primeira vez.