Réponse aux erreurs de restauration SQL Server provoquées par des sauvegardes endommagées

Mis à jour : 17 juillet 2006

Des erreurs de restauration se produisent si le support de sauvegarde est endommagé. Elles peuvent être signalées par le système d'exploitation ou détectées par les sommes de contrôle. Quel que soit le cas, vous avez trois possibilités :

• résoudre l'erreur et redémarrer l'opération de restauration.
• poursuivre la restauration malgré les erreurs et réparer la base de données une fois la restauration terminée.
• abandonner l'opération de restauration et utiliser un autre plan de récupération qui évite la sauvegarde endommagée.

Remarque :
Le support de sauvegarde ou le jeu de sauvegarde doit contenir les informations correctes minimales pour pouvoir être interprété en tant que Microsoft Tape Format. Dans le cas contraire, l'instruction RESTORE s'arrête et indique que le format de la sauvegarde n'est pas valide.

Résolution et redémarrage de l'opération de restauration

Les erreurs peuvent être résolues de plusieurs façons :

• Si une erreur s'est produite sur un périphérique à bandes, vous pouvez le nettoyer ou le remplacer.
• Pour les unités de disques, vous pouvez résoudre l'erreur de périphérique et remplacer le fichier endommagé.
• Si un support de sauvegarde est mis en miroir, vous pouvez remplacer le support endommagé par le support correspondant provenant d'un autre miroir.

Poursuite malgré les erreurs

Attention :
Spécifier WITH CONTINUE_AFTER_ERROR dans une instruction RESTORE tente de restaurer la base de données. Il existe néanmoins plusieurs types de corruption qui empêchent la récupération d'une base de données. Nous vous recommandons fortement d'éviter l'utilisation de l'option CONTINUE_AFTER_ERROR tant que toutes les solutions n'ont pas été considérées.

L'option CONTINUE_AFTER_ERROR entraîne la poursuite d'une opération de restauration après les erreurs et restaure ce qu'elle peut. Une restauration par progression se produit et les sauvegardes ultérieures des journaux de transactions peuvent être appliquées. Si la restauration par progression rencontre une erreur qui l'empêche d'atteindre le point chronologique cible, cette erreur est consignée dans le journal. Au point de récupération, la base de données est mise en ligne, dans la mesure du possible. Mais si la récupération ne peut se terminer, la base de données reste hors connexion.

La quantité de données perdues dépend de l'erreur rencontrée. Par exemple, une somme de contrôle incorrecte sur une page provoque une interrogation sur cette page uniquement ; la lecture et le traitement du support se poursuivent. Au contraire, une erreur d'E/S signalée sur un périphérique à bandes peut empêcher la restauration de lire après l'erreur, interdisant ainsi la restauration du reste de la bande.

Lorsqu'une restauration est paramétrée pour poursuivre après les erreurs, les pages qui échouent à la vérification sont inscrites sur le disque et consignées dans la table suspect_pages et dans le journal des erreurs.

Meilleures pratiques :  Après avoir utilisé WITH CONTINUE_AFTER_ERROR pour restaurer les données, examinez les journaux d'erreur pour en savoir plus sur les erreurs. N'oubliez pas non plus d'enregistrer et d'analyser tous les messages provenant directement de l'instruction RESTORE.

Pour continuer malgré les erreurs

• La syntaxe de base RESTORE est la suivante :
• RESTORE DATABASE database_name FROM backup_device WITH CONTINUE_AFTER_ERROR, [ NORECOVERY ]

Gestion de la base de données hors connexion

À la fin d'une séquence de restauration qui s'est poursuivie malgré les erreurs, il peut être possible de réparer la base de données avec DBCC CHECKDB. Pour que CHECKDB s'exécute le mieux possible après utilisation de RESTORE CONTINUE_AFTER_ERROR, nous vous recommandons d'utiliser l'option WITH TABLOCK dans votre commande DBCC CHECKDB. Pour plus d'informations, consultez DBCC CHECKDB (Transact-SQL). Toutes les options de réparation sont disponibles. Pour connaître le niveau minimal de réparation nécessaire, exécutez DBCC CHECKDB sans option de réparation. Notez que dans les cas extrêmes, la quantité d'informations peut être insuffisante pour réparer la base de données.

Pour accéder de manière limitée aux données telles qu'elles sont, vous pouvez placer la base de données en mode urgence à l'aide de l'option EMERGENCY de la commande ALTER DATABASE.

Voir aussi

Concepts

Présentation et gestion de la table suspect_pages

Autres ressources

ALTER DATABASE (Transact-SQL)
BACKUP (Transact-SQL)
DBCC CHECKDB (Transact-SQL)
RESTORE (Transact-SQL)
RESTORE VERIFYONLY (Transact-SQL)

Aide et Informations

Assistance sur SQL Server 2005

Historique des modifications

Version	Historique
17 juillet 2006	Nouveau contenu : Ajout d'une note d'avertissement et des meilleures pratiques à la section « Poursuite malgré les erreurs ».