Executando operações de atualização de dados ao fazer backup de um banco de dados grande do SQL Server

Eu tenho um banco de dados grande (nas dezenas de milhões de registros) em que vou executar um backup completo do banco de dados .

No entanto, o banco de dados é grande o suficiente para que as transações possam iniciar antes e durante, bem como confirmar durante e após o backup.

Por exemplo:

T0 = Transaction A start
T1 = Full database backup start
T2 = Transaction B start (will not deadlock with A)
T3 = Transaction A commit/rollback (does not matter, does it?)
T4 = Full database backup end
T5 = Transaction B commit/rollback (again, does not matter, does it?)

T0          T1          T2          T3          T4          T6
||----------||----------||----------||----------||----------||---------->

Meu entendimento é que nenhum bloqueio é usado durante um backup (embora outros problemas de desempenho possam surgir devido à alta E / S) , mas não tenho certeza do que posso garantir o que será confirmado ou não.

Além disso, minha preocupação não é que o banco de dados esteja em um estado inconsistente, mas o que será esse estado (mesmo que não seja determinístico, se houver um conjunto de regras que possa ser aplicado de forma consistente) e como ele chegou lá ( por exemplo, quanto do arquivo de dados é usado junto com o log de transações para criar um arquivo de backup)?

Essencialmente, o backup estará no estado do banco de dados quando concluir a parte de leitura de dados do backup (para que todos os dados sejam salvos em backup), mais a quantidade de log de transações necessária para garantir a consistência transacional (o início hora do log incluído é MIN(most recent checkpoint time, oldest active transaction start time)). Paul Randal cobre isso aqui (com a ajuda de um diagrama, o que torna tudo muito mais fácil). No seu exemplo, Aseria confirmado (ou revertido se um ROLLBACK TRANSACTIONfoi emitido em vez de a COMMIT) e Brevertido (independentemente do resultado final dessa transação).

(O outro motivo pelo qual você tenta fazer backups em um momento silencioso, além da contenção de E / S, é que todo o log de transações gerado durante um backup normalmente precisa ser incluído no backup.)

A fase de recuperação de uma restauração do banco de dados pega todas as transações confirmadas do log incluído no backup e as aplica ao banco de dados e reverte todas as transações não confirmadas. (É por isso que WITH RECOVERY/ WITH NORECOVERYé importante. WITH RECOVERYE você pode usar o banco de dados, mas não pode aplicar nenhum backup de log adicional, é necessário restaurá-lo WITH NORECOVERYpara fazer o roll-in dos backups de log. A recuperação interrompe a cadeia de logs revertendo transações não confirmadas. )

Leitura adicional:

• 30 mitos de backup do SQL Server
• Desmistificando alguns mitos sobre backups completos
• Log e recuperação no SQL Server

Um backup completo será restaurado no momento em que a parte de leitura de dados for concluída, menos as transações não confirmadas naquele momento.

Como você mencionou, o banco de dados permanece online e disponível para gravação enquanto o backup ocorre. Como isso funciona é que o sistema de backup faz backup de um conjunto inconsistente de páginas de dados (já que leva um tempo diferente de zero para ler os dados) - é necessária uma cópia de cada página de dados no que diz respeito a ela, qualquer que seja o estado in. Um backup completo também inclui registros de log de transações, começando do início da transação ativa mais antiga no início do backup, até o último registro de log quando a parte de leitura de dados é concluída.

Quando o backup é restaurado, os dados e o log são reconstituídos como estão (lembre-se de que as páginas de dados estão em um estado inconsistente) e o processo de refazer ocorre desde o início do log de transações de backup (novamente, dentro do backup completo) , todo o caminho até o fim; se você restaurou com RECOVERY, desfazer ocorre para reverter as transações não confirmadas no momento em que o backup foi concluído. A operação desfazer é o que deixa o banco de dados em um estado transacionalmente consistente, pronto para uso. A restauração com NORECOVERYignora o processo de desfazer , permitindo restaurar backups adicionais (diferencial ou log de transações).

Observe que, se o banco de dados for muito grande com uma carga de trabalho de gravação pesada, o log de transações poderá precisar aumentar durante o backup se houver espaço insuficiente atualmente alocado. O log não pode (internamente) ser limpo durante um backup completo, mesmo se você estiver fazendo backups de log de transações, pois os registros são necessários para o backup completo. Se você estiver executando backups de log de transações enquanto ocorre um backup completo, a limpeza do log é adiada automaticamente até que o backup completo seja concluído.