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

Question

Acabei de ler muita documentação do MSDN e acho que entendi 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 consegui encontrar foi que apenas BACKUP LOG trunca o log.

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

Answer 1

Não - definitivamente não. A única coisa que permite ao log limpar / truncar nos modelos de recuperação FULL ou BULK_LOGGED é um backup de log - sem exceções. Eu tive esse argumento há algum tempo e publiquei um longo e detalhado post no blog com uma explicação e um script que você pode usar para prová-lo em Equívocos em torno dos backups de log e log: como se convencer .

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

Obrigado

    

Answer 2

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 seria estragar a replicação / envio de log, etc.

Você teria que observar de perto como o SQL Server faz backups, mas sabe que transações em andamento / longas não estão incluídas no backup (caso contrário, o backup pode nunca ser concluído), por isso não é exato dizer que o backup de um banco de dados online é garantido para tornar obsoleto o próximo backup de log.

link

    

Answer 3

Do meu entendimento 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 ele seja transacionalmente consistente, porque leva um tempo para a operação de backup concluir & nesse tempo, as páginas copiadas podem ter mudado.

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

Não tenho o MSDN para vincular, mas posso vinculá-lo a O blog de Paul Randal , que era desenvolvedor da equipe do SQL Server, escreveu DBCC CHECKDB e partes de Books Online.

Ele também responde a perguntas neste fórum, de modo que seria uma autoridade ainda melhor do que a minha segunda / terceira mão:)

    

Answer 4

As pessoas geralmente têm um conceito errado sobre backups completos e backups de log. Para que o backup funcione no modelo de recuperação de backup FULL , os logs t devem ser usados, pois durante os backups ainda podem existir transações no banco de dados (a menos que você execute o chamado COLD backup quando desligar o banco de dados). O Oracle usa o mesmo conceito quando você tem um banco de dados no modo ARCHIVELOG . A sequência de um backup resume-se 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 logs t
3. Encerrar backup - retomar a gravação de transações do banco de dados em arquivos reais.
4. Se necessário, esvazie o que está nos registros T nos arquivos reais.

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

    

Answer 5

Não confunda o truncamento do log com o encolhimento do log.

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

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

Answer 6

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