Caminhos de recuperação
É importante entender os caminhos de recuperação se você usar backup diferencial ou de log, e recuperar um banco de dados para um momento anterior usando um dos seguintes métodos:
Executando uma restauração point-in-time
Executando uma recuperação sem restaurar primeiro todos os backups de log ou o backup diferencial mais recente.
Se você recuperar um banco de dados para um ponto de recuperação anterior e começar a usar o banco de dados a partir desse ponto, um novo caminho de recuperação será originado. Caminho de recuperação é a seqüência de backups de dados e log que levaram um banco de dados a um determinado ponto, seja pelo uso normal do banco de dados ou por uma restauração específica de dados e log. Esse caminho consiste em um conjunto exclusivo de transformações específicas que fizeram com que o banco de dados evoluísse com o passar do tempo, ao mesmo tempo mantendo a sua consistência. A ilustração seguinte mostra a relação entre um ponto de recuperação e os caminhos de recuperação resultantes.
.gif "Caminhos do ponto de recuperação e da recuperação resultante")
As situações seguintes criam um novo caminho de recuperação porque o banco de dados não é restaurado até o "fim". Conseqüentemente, existem backups que podem levar o banco de dados para dois ou mais caminhos de recuperação abaixo. Esses caminhos usam o mesmo intervalo de LSNs.
Restauração de um backup completo de banco de dados e recuperação do banco de dados sem usar qualquer outro tipo de backup.
Recuperação do banco de dados ao término de um backup diferencial que não seja o mais recente.
Restauração de um backup completo do banco de dados e de um backup diferencial do banco de dados, e recuperação do banco de dados sem aplicar os backups de log de transações existentes.
Recuperação do banco de dados ao término de um backup de log de transações que não seja o mais recente.
Recuperação do banco de dados em um momento específico ou uma transação marcada em um backup de log de transações.
Em geral, um ponto de recuperação iniciará um novo caminho de recuperação se o ponto de recuperação fizer com que as transações sejam revertidas. Os backups preexistentes agora podem ter LSNs (números de seqüência de log) maiores do que o LSN desse ponto de recuperação. Os LSNs desses backups existem em uma ramificação de recuperação diferente da nova ramificação criada pela operação de recuperação atual.
Prática recomendável Para evitar a criação de um caminho de recuperação com várias bifurcações de recuperação, execute um conjunto completo de backups de dados assim que for possível, após recuperar o banco de dados. Esta abordagem garante que todos os backups sejam feitos em uma única ramificação de recuperação. Para verificar isso, você pode examinar a coluna last_recovery_fork_guid na tabela backupset ou o conjunto de resultados de RESTORE HEADERONLY após fazer backup dos dados.
Exemplo de um caminho de recuperação
Inicialmente, todos os backups de um banco de dados formam um único caminho de recuperação, como mostra a ilustração a seguir. Nessa ilustração, o caminho de recuperação contém um backup de banco de dados feito na hora t1, e três backups de log feitos nas horas t2, t3 e t4.
.gif "Caminho de recuperação original")
A ilustração a seguir mostra uma bifurcação de recuperação resultante da recuperação do banco de dados para um ponto antigo. Um problema com o backup t4 faz com que o administrador do banco de dados o recupere no fim do backup de log t3. Essa restauração causa uma bifurcação de recuperação. Na hora t5, um novo backup de log inicia uma nova ramificação de recuperação, a ramificação 2.
.gif "Criação de uma segunda ramificação de recuperação")
.gif "Observação") Observação |
|---|
O backup de log t5 contém metadados da bifurcação de recuperação que conecta esse backup ao backup de log t3 na ramificação de recuperação 1. Para obter informações sobre metadados de bifurcação de recuperação, consulte "Gerenciando bifurcações de recuperação", mais adiante neste tópico. |
O exemplo mostrado na ilustração anterior cria um novo caminho de recuperação, o qual é mostrado na ilustração a seguir. O novo caminho de recuperação contém alguns dos backups na ramificação de recuperação 1 (t1 a t3) e todos os backups de log na ramificação de recuperação 2 (t5 a t9). Da perspectiva desse caminho de recuperação, o backup de log t4 é obsoleto.
.gif "Novo caminho de recuperação")
Após uma restauração point-in-time, o backup seguinte sempre causa uma bifurcação de recuperação. Na ilustração a seguir, uma restauração point-in-time é concluída na metade do backup de log t4. A recuperação do banco de dados para esse ponto gera uma bifurcação de recuperação. Em seguida, um backup de log é criado no banco de dados recuperado na hora t5, estabelecendo a ramificação de recuperação 2 e criando um novo caminho de recuperação. O primeiro backup de log na nova ramificação, t5, contém o mesmo primeiro LSN do backup de log t3 e o substitui. Portanto, ambos os backups, t3 e t4, são obsoletos no novo caminho de recuperação.
.gif "Novo caminho de recuperação depois de uma restauração pontual")
Para restaurar backups nesse novo caminho de recuperação, a seqüência de restauração é: t1, t2 e t5. À medida que os futuros backups forem feitos na ramificação de recuperação 2, eles serão incorporados no novo caminho de recuperação.
Para restaurar e efetuar roll forward ao longo de um caminho antigo
Geralmente, quando existem vários caminhos de recuperação, o mais novo deles é o caminho preferido para restaurar o banco de dados. É recomendável que você evite usar um caminho de recuperação antigo. No entanto, se isso for necessário, efetue roll forward em um caminho de recuperação antigo de acordo com a seqüência de backups feitos antes da criação do caminho de recuperação atual. Por exemplo, é possível usar backups feitos antes de uma recuperação pontual para atingir pontos mais recentes ao longo do caminho antigo.
Por exemplo, com base nos backups criados na ilustração anterior, após a criação do backup de log t5, ainda é possível restaurar desde o backup completo do banco de dados feito em t1 até o fim do backup de log t4 Isso está no caminho de recuperação antigo.
Para restaurar e efetuar roll forward de um caminho antigo para um novo caminho
O Mecanismo de banco de dados do SQL Server evita que uma seqüência de restauração use backups que não combinem, ou seja, que tente efetuar roll forward ao longo de diferentes caminhos de recuperação. Essa restrição mantém a consistência de um banco de dados após uma recuperação.
Para restaurar e efetuar roll forward ao longo de um novo caminho de recuperação, construa seqüências de restauração distintas para os backups antes do ponto de recuperação e para os backups após o ponto de recuperação:
Restaure os backups feitos antes da recuperação que introduziu o novo caminho de recuperação. Exclua o backup que contém o ponto de recuperação.
Efetue roll forward ao longo do novo caminho de recuperação restaurando os backups que foram feitos desde a criação do caminho de recuperação.
Gerenciando bifurcações de recuperação
Ramificação de recuperação é um intervalo de LSNs que compartilham o mesmo GUID. O caminho de recuperação descreve um intervalo de LSNs de um ponto inicial (LSN, GUID) para um ponto de extremidade (LSN, GUID). O intervalo de LSNs em um caminho de recuperação pode atravessar uma ou mais ramificações de recuperação, do início ao fim. Uma nova ramificação de recuperação tem origem quando um banco de dados é criado e quando RESTORE WITH RECOVERY gera uma bifurcação de recuperação.
Bifurcação de recuperação é o ponto (LSN,GUID) em que uma nova ramificação de recuperação é iniciada, sempre que um RESTORE WITH RECOVERY é executado. Cada bifurcação de recuperação determina uma relação pai-filho entre as ramificações de recuperação.
A recuperação do banco de dados define o estado do banco de dados inteiro, inclusive o próximo LSN, para o ponto de recuperação. Os LSNs então são reutilizados, começando pelo fork_point_lsn. Portanto, na construção de uma seqüência de restauração, os backups devem ser vinculados por bifurcação de recuperação e também por LSN, pois o mesmo LSN pode existir em mais de uma bifurcação. A ilustração a seguir mostra a reutilização do LSN. Ela mostra como os LSNs são reutilizados em bifurcações de recuperação diferentes. As caixas verdes da ilustração indicam dois backups que usam o mesmo LSN.
.gif "Como os LSNs são reutilizados em bifurcações de recuperação diferentes")
Se uma seqüência de restauração precisar incorporar backups que atravessam uma bifurcação de recuperação, a seqüência de restauração deverá ser construída de forma que os backups que forem usados sigam o caminho de recuperação correto para o ponto de recuperação. Para este propósito, os backups contêm um GUID da primeira bifurcação de recuperação e um GUID da última bifurcação de recuperação.
Esses GUIDs, juntamente com outros metadados relevantes para o rastreamento dos caminhos de recuperação, são armazenados na tabela de histórico backupset e também são retornados pela instrução RESTORE HEADERONLY. A tabela a seguir resume os valores dos metadados relevantes para a construção de seqüências de restauração que atravessam uma bifurcação de recuperação. Observe que os nomes de coluna desses valores são diferentes para a tabela de histórico e para o conjunto de resultados da instrução RESTORE HEADERONLY:
LSN |
Descrição |
nome da coluna backupset |
nome da coluna RESTAURE HEADERONLY |
|---|---|---|---|
GUID da primeira bifurcação de recuperação |
ID da bifurcação de recuperação inicial. |
first_recovery_fork_guid |
FirstRecoveryForkID |
GUID da última bifurcação de recuperação |
ID da bifurcação de recuperação final. |
last_recovery_fork_guid |
RecoveryForkID |
Primeiro LSN |
Número de seqüência de log do primeiro ou mais antigo registro de log no conjunto de backup. |
first_lsn |
FirstLSN |
Último LSN |
Número de seqüência de log do próximo registro de log após o conjunto de backup. |
last_lsn |
LastLSN |
LSN do ponto de bifurcação |
Número de seqüência de log de um ponto de bifurcação, se o GUID do primeiro ponto de recuperação não for igual (≠) ao GUID do último ponto de recuperação. Caso contrário, nenhuma bifurcação de recuperação ocorrerá no backup e o LSN do ponto de bifurcação será NULL. |
fork_point_lsn |
ForkPointLSN |
GUID de base diferencial |
Para um backup diferencial de base única, o valor é o identificador exclusivo da base diferencial. Para diferenciais com várias bases, o valor é NULL, e a base diferencial deve ser determinada em nível de arquivo. Para obter mais informações, consulte backupfile (Transact-SQL). Para tipos de backup não diferenciais, o valor é NULL. |
differential_base_guid |
DifferentialBaseGUID |
O restante desta discussão usa só os nomes de valores na tabela de histórico backupset.
O GUID da última bifurcação de recuperação e o GUID da primeira bifurcação de recuperação são usados para vincular os backups para ter certeza de que a seqüência siga a bifurcação correta. Para cada backup de log da seqüência a ser restaurado, o first_recovery_fork_guid deve ser igual ao last_recovery_fork_guid do backup anterior da seqüência.
.gif "first_recovery_fork_guid = last_recovery_fork_guid")
Também devem ser vinculados os backups de dados e diferenciais.
Se o backup de log contiver o último LSN de um backup de banco de dados completo, ou de um backup de banco de dados diferencial, e um ponto de bifurcação, o teste de vinculação dependerá do local do último LSN em relação ao ponto de bifurcação.
Os testes de vinculação são os seguintes, usando valores de backupset:
Se last_lsn for menor ou igual a fork_point_lsn, o last_recovery_fork_guid do backup de dados ou diferencial deverá ser igual ao first_recovery_fork_guid do backup de log. A ilustração a seguir mostra um caso em que last_lsn é menor que fork_point_lsn.
.gif "last_lsn é menor que fork_point_lsn")
Se last_lsn for maior que fork_point_lsn, o last_recovery_fork_guid do backup de dados ou diferencial deverá ser igual ao last_recovery_fork_guid do backup de log. A ilustração a seguir mostra um caso em que last_lsn é maior que fork_point_lsn.
.gif "last_lsn é maior que fork_point_lsn")
Para um backup diferencial, localize a base diferencial usando backupset.differential_base_guid.
Se o diferencial for com várias bases, backupset.differential_base_guid será o NULL e você deverá determinar as bases diferenciais arquivo por arquivo usando backupfile.differential_base_guid.
Consulte também