Artigo
09/28/2010

Respondendo a erros de restauração dos SQL Server causado por backups danificados

Restaurar erros ocorre se a mídia de backup estiver danificada. Restaurar erros pode ser relatado pelo sistema operacional ou detectado através de somas de verificação. Em todo caso, você tem três opções:

Corrija o erro e reinicialize a operação de restauração.
Permita que a restauração prossiga apesar dos erros e repare o banco de dados após a conclusão da restauração.
Abandone a operação de restauração e use um plano de recuperação alternativo que evita o backup danificado.

Observação
O conjunto de mídia ou o conjunto de backup deve conter informações corretas mínimas para ser interpretado como Microsoft Formatar fita. Se este não for o caso, RESTORE pára e indica que o formato do backup é inválido.

Corrigindo e reiniciando a operação de restauração.

Os erros podem ser corrigidos das seguintes maneiras:

Se um erro aconteceu em um dispositivo de fita, você pode limpar ou substituir a unidade de fita.
Para dispositivos de disco, você pode resolver o erro de dispositivo e substituir o arquivo danificado.
Se um conjunto de mídia for espelhado, você pode substituir a mídia danificada pela mídia correspondente de outro espelho.

Continuando apesar dos erros

Cuidado
Especificando WITH CONTINUE_AFTER_ERROR em uma instrução RESTORE tenta restaurar o banco de dados. Porém, há muitos tipos de corrupção que impedem a recuperação de um banco de dados. É altamente recomendável que você reserve usando a opção CONTINUE_AFTER_ERROR até que esgote todas as alternativas.

A opção CONTINUE_AFTER_ERROR resulta em uma operação de restauração para continuar erros anteriores, restaurando o que é possível. Roll forward acontece e é possível aplicar backups de log de transações subseqüentes. Se roll forward encontra um erro que o impede de atingir o ponto designado a tempo, este erro será indicado no log. No ponto de recuperação, o banco de dados é colocado online, se assim puder. Mas se a recuperação não puder ser concluída, o banco de dados será deixado offline.

A quantidade de dados perdidos depende do erro encontrado. Por exemplo, uma soma de verificação ruim em uma página resulta apenas naquela página a ser interrogada; a mídia continua sendo lida e processada. Em contraste, um erro de E/S informado de um dispositivo de fita pode evitar a restauração de leitura de um erro anterior, evitando que o restante da fita seja restaurado.

Quando uma restauração é instruída a continuar depois dos erros, as páginas que falham a verificação são gravadas a disco e registradas na tabela suspect_pages e no log de erros.

Práticas melhores: Depois que você usar WITH CONTINUE_AFTER_ERROR para restaurar dados, examine os logs de erros para obter detalhes nos erros. Também, salve e analise todas as mensagens que você obtém diretamente da instrução RESTORE.

Para continuar apesar de erros

A sintaxe básica RESTORE é:

RESTORE DATABASE database_name FROM backup_device WITH CONTINUE_AFTER_ERROR, [ NORECOVERY ]

Gerenciando o banco de dados como Offline.

Ao término de uma seqüência de restauração que continua apesar de erros, você pode reparar o banco de dados com DBCC CHECKDB. Para CHECKDB executar com mais consistência depois de usar RESTORE CONTINUE_AFTER_ERROR, nós recomendamos que você use a opção WITH TABLOCK em seu comando DBCC CHECKDB. Para obter mais informações, consulte DBCC CHECKDB (Transact-SQL). Todas as opções de reparo estão disponíveis. Para aprender o nível de conserto mínimo necessário, execute DBCC CHECKDB sem uma opção de reparo. Note que, em casos extremos, pode não haver informações suficientes para reparar o banco de dados.

Para ganhar acesso limitado aos dados no estado em que se encontram, você pode colocar o banco de dados em modo de emergência usando a opção EMERGENCY do comando ALTER DATABASE.