Banco de dados em recuperação simples para economizar espaço

Primeiro, uma nota rápida sobre a mudança para a SIMPLErecuperação. Esta é uma decisão de negócios. Não é de forma alguma uma decisão técnica. Sua empresa precisa pesar o custo de permanecer FULL(o que pode significar um novo servidor com espaço adicional, arquivar dados atuais para liberar algum espaço, etc.) versus o custo de perder até um dia ou mais de dados. Depois que eles decidirem, você poderá prosseguir.

Com base na sua pergunta e nos comentários, vejo um dos dois cenários:

Você está no FULLmodo de recuperação, mas não está fazendo backups de log.

Neste ponto, você precisa começar a fazer backups de log regularmente. Com toda a probabilidade, isso realmente economizará espaço. Se você fizer um backup de log para limpar o log menos de uma vez por dia ( Nota: FULLbackups não liberam espaço de log ), então seu log de transações provavelmente é maior do que o necessário. Coloque seus backups em ordem e, em seguida, descubra o tamanho que seu log de transações realmente precisa ter. Com toda a probabilidade, será um pouco menor do que atualmente, oferecendo espaço adicional para backups. Na pior das hipóteses, mova seus backups para fita com mais frequência do que atualmente.

Você está no FULLmodo de recuperação, mas está fazendo backups de log.

Se for esse o caso, talvez seja necessário aumentar a frequência dos backups de log. Isso não incorrerá em requisitos de espaço adicionais, pois os arquivos de log serão apenas menores (há uma pequena sobrecarga para informações de cabeçalho, mas não é tão significativa). Isso permitirá que seu registro seja limpo mais rapidamente e permaneça menor. Supondo (e esta é uma grande suposição) que você não tenha uma ou mais transações individuais que exijam o espaço de log. Se for esse o caso, apenas alterar seu código para diminuir o tamanho de suas transações permitirá que você consiga um arquivo de log menor. Mesmo se você mudar paraSIMPLErecuperação, você ainda precisará de espaço de log para a maior transação única (ou maior combinação de transações simultâneas). Se você reduzir seu arquivo de log e executar uma transação que precise de mais espaço do que o disponível, o log aumentará novamente.

Mais uma vez, alternar entre FULLe SIMPLErecuperação é uma decisão de negócios . Tomar esse tipo de decisão sem consultar a empresa (e depois errar) é uma boa maneira de ser demitido.

Você está certo, você não pode recuperar um banco de dados que possui um modelo de recuperação SIMPLES além do último backup completo. Além disso, você apontou o motivo pelo qual deveria ter este banco de dados no modelo de recuperação COMPLETO: "ele ainda tem muitos usuários fazendo transações, então o arquivo de log do único banco de dados que está neste servidor preenche a unidade de dados todos os dias." Você realmente deseja perder os dados dos quais muitos usuários dependem?

Não.

Tente backups de log de transações a cada hora (ou 15 minutos, se você puder pagar pelo espaço) e salve os arquivos .trn na unidade de backup. Configure uma tarefa de limpeza para excluir os arquivos .trn a cada poucos dias se você fizer um backup completo diário. Problema resolvido.

Aqui está outro motivo pelo qual você deve permanecer no modelo de recuperação FULL: Imagine que um novo funcionário derrube critical_table no banco de dados às 12h35 e o aplicativo que usa o banco de dados cai. Você pode fazer um backup do log de transações aqui, restaurar o backup completo em um novo banco de dados** e, em seguida, restaurar o .trn com uma parada às 12h34 e recuperar os dados!

**se a cadeia de logs for interrompida entre o último backup completo e o backup tlog que você acabou de criar, você estará desossado, portanto, não restaure o banco de dados antigo até ter certeza de que pode restaurar os dois juntos.