Artigo
09/28/2010

Planejando uma seqüência de restauração por etapas para um arquivo em restauração, recuperação pendente ou offline

Este tópico só é pertinente para bancos de dados do SQL Server que contêm diversos grupos de arquivos (e, no modelo simples, só para grupos de arquivos somente leitura) quando você estiver planejando uma recuperação por etapas de um banco de dados.

Se uma seqüência de restauração envolve um arquivo no estado restauração, recuperação pendente ou offline, talvez seja possível recuperar o arquivo sem restaurar seus dados. Para determinar se deve restaurar um backup completo do arquivo ou se pode simplesmente recuperar o arquivo, você pode usar metadados armazenado nas exibições de catálogos sys.database_files e sys.master_files.

LSNs de refazer

O primeiro passo é inspecionar as colunas da exibição de catálogo que contêm os LSNs de refazer: redo_start_lsn, redo_start_fork_guid, redo_target_lsne redo_target_fork_guid. A tabela abaixo descreve os LSNs de refazer e como interpretá-los.

Colunas	Descrição
redo_start_lsn e redo_start_fork_guid	Juntas, estas colunas descrevem um par (lsn,guid) que representa o point-in-time do arquivo. À medida que é efetuado o roll forward no arquivo, os valores dessas colunas mudam. O roll-forward continua a partir deste ponto. Importante Se redo_start_lsn = NULL, o estado em disco do arquivo será desconhecido e o arquivo deverá ser restaurado a partir de um backup completo.
redo_target_lsn e redo_target_fork_guid	Juntas, estas colunas descrevem um par (lsn,guid) que define o ponto de recuperação no qual o arquivo deve ser restaurado para ficar consistente com o banco de dados online (o ponto de recuperação de destino).

Decidindo se deve ser usado o sys.database_files ou o sys.master_files

As exibições do catálogo sys.database_files e sys.master_files contêm as colunas de LSN de refazer, mas nem sempre são consistentes. Geralmente, se o banco de dados está online, os valores em sys.database_files e sys.master_files são consistentes. Porém, os valores serão inconsistentes nas seguintes situações:

Se o banco de dados for somente leitura, sys.database_files não será atualizado com qualquer mudança causada pelo backup e só o sys.master_files conterá informações atualizadas.

Observação
Para descobrir se um arquivo é somente leitura, examine as colunas is_read_only e read_only_lsn; is_read_only indica se o arquivo é somente leitura. Nesse caso, read_only_lsn é o ponto no qual o arquivo tornou-se somente leitura.

Se o banco de dados estiver offline (por exemplo, quando está sendo restaurado), o catálogo do banco de dados estará inacessível. Em um banco de dados offline, você deve usar sys.master_files para obter informações.
Se uma operação de restauração estiver afetando o arquivo atualmente, os LSNs de refazer do arquivo estão sendo atualizados e estão inconsistentes. Você deve examinar as colunas de LSNs de refazer somente entre as restaurações.

Interpretação destas colunas

Observação
Esta seção pressupõe que você está familiarizado com os conceitos de caminho de recuperação e bifurcação de recuperação. Para obter mais informações, consulte Caminhos de recuperação.

Esta seção só será pertinente se você executou a recuperação de point-in-time e ainda tem backups de caminhos de recuperação extintos. Quando você está restaurando um arquivo no estado de restauração, recuperação pendente ou offline, as bifurcações de recuperação são pertinentes. Analisando as bifurcações de recuperação, você pode identificar caminhos de recuperação potencial. Geralmente, um caminho de recuperação será claramente melhor para recuperar o banco de dados.

Para identificar o melhor caminho de recuperação, você tem que descobrir se o arquivo está na bifurcação de recuperação de destino ou em outra bifurcação de recuperação:

O arquivo está em outra bifurcação de recuperação.

Se redo_start_fork_guid ! = redo_target_fork_guid e não é um ancestral do redo_target_fork_guid, o arquivo está em uma bifurcação de recuperação diferente da bifurcação de destino.

Observação
Para localizar uma bifurcação ancestral, siga a cadeia de logs retroativamente. Para obter mais informações, consulte Caminhos de recuperação.

Neste caso, o arquivo deve ser restaurado de um backup completo. Essa restauração posicionará o arquivo em um ponto ancestral válido do ponto de recuperação atual do banco de dados.

Observação
Para restaurar um arquivo, o backup do arquivo deve ser um ancestral do ponto de recuperação do banco de dados. Sempre procure o backup completo mais recente do arquivo. Devem ser efetuados rollf rowards nos dados até o ponto de destino. A única exceção é que o backup de um arquivo somente leitura não precisa ter um roll foward efetuado se o arquivo era somente leitura desde antes do backup. Se for necessário, depois de restaurar o backup do arquivo, restaure um backup de arquivo diferencial, se houver, e backups de log para trazer o arquivo ao ponto de recuperação de destino.

Para restaurar um arquivo, o backup do arquivo deve ser um ancestral do ponto de recuperação do banco de dados. Sempre procure o backup completo mais recente do arquivo. Devem ser efetuados rollf rowards nos dados até o ponto de destino. A única exceção é que o backup de um arquivo somente leitura não precisa ter um roll foward efetuado se o arquivo era somente leitura desde antes do backup. Se for necessário, depois de restaurar o backup do arquivo, restaure um backup de arquivo diferencial, se houver, e backups de log para trazer o arquivo ao ponto de recuperação de destino.

O arquivo está na bifurcação de recuperação atual (destino) ou é um ancestral da bifurcação de destino.

Observação
Se você executou um backup do arquivo desde a recuperação do banco de dados, o arquivo estará na bifurcação de recuperação de destino.

Nesses casos, se o arquivo deve ser restaurado depende da relação de redo_start_lsn com redo_target_lsn, como descrito na tabela abaixo.

Se...	Então...
redo_start_lsn =redo_target_lsn	O arquivo não precisa ser restaurado. O arquivo é consistente com o banco de dados e pode ser colocado online sem usar RESTORE DATABASE database_name WITH RECOVERY.
redo_start_lsn <redo_target_lsn	Antes de o arquivo poder ser colocado online, o roll-forward deve alcançar redo_target_lsn.
redo_start_lsn >redo_target_lsn	O banco de dados é anterior ao arquivo. O arquivo deve ser restaurado de um backup completo (ou o banco de dados pode ser restaurado novamente a um point-in-time posterior com outra seqüência de restauração parcial). Observação Essa situação só pode acontecer para uma restauração offline, porque assim que o grupo de arquivos primário for recuperado, será gerada uma nova bifurcação de recuperação. Quaisquer grupos de arquivos secundários não recuperados não estão mais no mesmo caminho de recuperação que o grupo de arquivos primário.

redo_start_lsn =redo_target_lsn

O arquivo não precisa ser restaurado.

O arquivo é consistente com o banco de dados e pode ser colocado online sem usar RESTORE DATABASE database_name WITH RECOVERY.

redo_start_lsn <redo_target_lsn

Antes de o arquivo poder ser colocado online, o roll-forward deve alcançar redo_target_lsn.

redo_start_lsn >redo_target_lsn

O banco de dados é anterior ao arquivo. O arquivo deve ser restaurado de um backup completo (ou o banco de dados pode ser restaurado novamente a um point-in-time posterior com outra seqüência de restauração parcial).

Observação

Essa situação só pode acontecer para uma restauração offline, porque assim que o grupo de arquivos primário for recuperado, será gerada uma nova bifurcação de recuperação. Quaisquer grupos de arquivos secundários não recuperados não estão mais no mesmo caminho de recuperação que o grupo de arquivos primário.

Observação
Depois que você restaurar os backups de um desses caminhos de recuperação, os caminhos de recuperação alternativos não serão mais válidos. Backups específicos a um caminho de recuperação inválido se tornarão extintos. A prática recomendada é excluir backups extintos ou colocá-los de lado e marcá-los claramente como extintos.