SQL Server (2005/2008): o backup completo trunca o log no modo de recuperação completa


41

Acabei de ler muita documentação do MSDN e acho que entendo os diferentes modelos de recuperação e o conceito de uma cadeia de backup. Eu ainda tenho uma pergunta:

Um backup completo do banco de dados trunca o log de transações (usando o modo de recuperação completa)?

  • Se sim: Onde isso é mencionado no MSDN? Tudo o que pude encontrar foi que apenas o BACKUP LOG trunca o log.

  • Se não: por quê? Como um backup completo do banco de dados inicia uma nova cadeia de backups, qual é o sentido de manter as transações finalizadas antes do backup completo ativo no log?

Respostas:


43

Não - definitivamente não. A única coisa que permite que o log limpe / trunque nos modelos de recuperação COMPLETO ou BULK_LOGGED é um backup de log - sem exceções. Eu tive esse argumento há algum tempo e publiquei um post longo e detalhado com uma explicação e um script que você pode usar para provar a si mesmo em Conceitos errôneos sobre os logs e backups de log: como se convencer .

Sinta-se livre para acompanhar mais perguntas. Btw - veja também o longo artigo que escrevi para a TechNet Magazine sobre Noções básicas sobre log e recuperação no SQL Server .

obrigado


Muito obrigado, senhor, pela sua SUPER RESPOSTA e pelo artigo que respondeu a um milhão de perguntas em minha mente.
precisa saber é

13

Um backup completo NÃO trunca o log, você deve executar uma operação de log de backup. Um backup completo NÃO redefine a cadeia de logs - isso estragaria totalmente a replicação / envio de logs, etc.

Você precisaria examinar atentamente como o SQL Server faz backups, mas sabe que as transações em andamento / em execução longa não estão incluídas no backup (caso contrário, o backup pode nunca ser concluído), portanto, não é preciso dizer com precisão que um backup completo de um O banco de dados online é garantido para tornar o próximo backup de log obsoleto.

http://msdn.microsoft.com/en-us/library/ms175477.aspx


8

Pelo que entendi, a única coisa que trunca o log de transações é um backup de log .

Um backup completo apenas copia o suficiente do log para que seja consistente em termos de transação, porque leva um tempo para a operação de backup ser concluída e, nesse período, as páginas copiadas podem ter sido alteradas.

Você ainda precisa de seus backups de log para recuperação pontual.

Não tenho o MSDN para vincular, mas posso vincular você ao blog de Paul Randal , que foi desenvolvedor da equipe do SQL Server, escreveu DBCC CHECKDB e partes dos Books Online.

Ele também responde perguntas neste fórum, de modo que seria uma autoridade ainda melhor do que as informações de segunda e terceira mão de minha parte :)


5

As pessoas geralmente têm um conceito errado sobre os backups completos e de log. Para que o backup funcione no FULLmodelo de recuperação de backup, os logs t devem ser usados, pois durante os backups ainda pode haver transações em andamento no banco de dados (a menos que você execute um COLDbackup chamado ao desligar o banco de dados). O Oracle usa o mesmo conceito quando você tem um banco de dados no ARCHIVELOGmodo. A sequência de um backup se resume a isso:

  1. Iniciar backup - suspenda todas as ações em arquivos reais e grave em t-logs.
  2. Executar backup - todas as transações continuam, mas não são gravadas em arquivos reais, elas são gravadas em t-logs
  3. Finalizar backup - continue gravando transações do banco de dados em arquivos reais.
  4. Se necessário, libere o conteúdo dos logs T nos arquivos reais.

Essa é a razão pela qual os logs t não são, por padrão, truncados / diminuídos, pois são uma parte vital da continuação da transação durante a fase de backup.


1

Não confunda truncar o log com diminuir o log.

  • TRUNCATE é remover as transações no log anteriores ao último ponto de verificação (o ponto de verificação é quando as transações são liberadas no próprio banco de dados). Isso é feito usando o comando BACKUP.

  • Para SHRINK, o log é reduzir o tamanho real do arquivo de log. Isso é feito usando comandos DBCC.


1

Basicamente, você não precisa reduzir o log de transações automaticamente todas as vezes porque os logs de transações precisam de espaço para funcionar e, se você truncar automaticamente, ele permanecerá quase do mesmo tamanho.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.