Tenho vários bancos de dados que gostaria de mover para o modo de recuperação TOTAL para que possamos ter o recurso de restauração pontual. Não precisamos dele em todos os nossos bancos de dados, apenas naqueles que são pesados em transações e contêm dados que estão sendo constantemente atualizados.
Eu fiz muitas pesquisas e entendo perfeitamente o que acontece quando você muda para a recuperação COMPLETA, especialmente no que diz respeito ao arquivo de log.
O que estou procurando são algumas sugestões ou 'pegadinhas' que podem surgir da mudança de alguns para o modelo de recuperação COMPLETO.
No momento, planejo fazer um banco de dados por vez, para poder monitorar o crescimento do arquivo de log e determinar a melhor frequência para backups de arquivo de log para garantir que não entremos em uma situação de arquivo de log descontrolado. Também estou ciente de que, assim que mudarmos para a recuperação COMPLETA, precisarei executar um backup completo nesse banco de dados. (Entendo que o modo COMPLETO não será realmente ativado até que façamos isso).
Meu plano também é executar semanalmente um backup completo, limpar os arquivos de log da semana anterior e, basicamente, 'recomeçar'.
Existem outras considerações ou conselhos que seriam úteis. Algo que eu deveria observar? Também executamos reconstruções completas de índices, DBCC CHECKDB e reconstruções de estatísticas uma vez por semana. Há algum problema potencial com essas operações (talvez mude para BULK_LOGGED para esse período de tempo para não explodir o arquivo de log?)
Obrigado por toda sua ajuda!
Há muitas coisas que eu gostaria de dizer
Tanto quanto eu sei, se você alterar o modelo de recuperação do banco de dados durante a janela de manutenção ou quando a carga for relativamente menor, não haverá nenhum problema. Não vai criar uma situação.
Você também pode fazer backup diferencial, talvez isso seja muito útil se você tiver um grande banco de dados. qualquer coisa que vincule as cadeias LSN serviria. Veja o link abaixo, que contém boas informações sobre como alternar entre os modelos de recuperação
http://msdn.microsoft.com/en-gb/library/ms189272.aspx
Pare por aí, esta não é a abordagem correta apenas porque você fez um backup completo e um backup de log. Por favor, não pense que você pode remover com segurança arquivos de log antigos e backup completo. Você tem um plano para testar o backup antigo restaurando para realmente ver se, em caso de desastre, esses arquivos de backup funcionariam. Lembre-se de que apenas uma restauração bem-sucedida garante que seu backup seja totalmenteconsistente. Você tem a opção de verificar a integridade do backup. Caso contrário, inclua-o em seu plano de backup. Pelo menos, mantenha os arquivos de backup de 4 dias (isso é o que eu faço no disco local) antes de excluir os backups. Às vezes, as empresas desejam apenas alterações específicas de dados para as quais foram feitas alguns dias. Eu também tenho meu backup de banco de dados em fita e essa fita é armazenada por 6 meses.
Alterar o modelo de recuperação para log em massa e fazer a operação de log em massa faria com que você perdesse a recuperação do ponto no tempo (PIT), portanto, se você estiver preocupado com a recuperação do PIT, não faça isso. Em vez disso, reconstrua o índice por meio de script inteligente que reconstrói apenas o índice fragmentado como uma solução de reconstrução de índice de Ola Hallengren , observe que, se o índice for reconstruído com verificação completa, as estatísticas do índice já serão atualizadas com o processo de reconstrução.
Se você fizer DML pesado, divida-o em lotes para não explodir os arquivos de log.
Quando você está agendando suas reconstruções de índice, isso ocorre durante uma janela de manutenção sem atividades do usuário do aplicativo? A linha de negócios pode precisar de recuperação pontual (PIT), então deixe em FULL e monitore; ou obter exceção para esta janela. Parece que você definiu o escopo dessa alteração. OK! Boa sorte.