Détection et gestion des erreurs de support aux cours d'opérations de sauvegarde et de restauration
Microsoft SQL Server 2005 et les versions ultérieures vous donnent la possibilité de récupérer une base de données en dépit d'erreurs détectées. Un nouveau et important mécanisme de détection d'erreur est la création facultative d'une somme de contrôle de sauvegarde qui peut être créée par une opération de sauvegarde et validée par une opération de restauration. Vous pouvez déterminer si une opération recherche la présence d'erreurs et si elle s'arrête ou si elle continue en présence d'une erreur. Si une sauvegarde contient une somme de contrôle de sauvegarde, les instructions RESTORE et RESTORE VERIFYONLY peuvent rechercher la présence d'erreurs.
[!REMARQUE]
Les sauvegardes en miroir offrent jusqu'à quatre copies (miroirs) d'un support de sauvegarde, auxquelles vous pouvez recourir pour effectuer une récupération à partir d'erreurs causées par un support endommagé. Pour plus d'informations, consultez Utilisation de supports de sauvegarde miroirs.
Sommes de contrôle pendant l'exécution de l'instruction BACKUP
SQL Server prend en charge trois types de sommes de contrôle : une somme de contrôle sur les pages, une somme de contrôle dans les blocs de journal et une somme de contrôle de sauvegarde. Lorsqu'elle génère une somme de contrôle de sauvegarde, l'instruction BACKUP vérifie que les données lues depuis la base de données sont cohérentes avec toute indication de somme de contrôle ou de page endommagée présente dans la base de données.
L'instruction BACKUP peut aussi calculer une somme de contrôle de sauvegarde sur le flux de sauvegarde ; si des informations de page endommagée ou de somme de contrôle de page sont présentes dans une page donnée, lors de la sauvegarde de la page, l'instruction BACKUP vérifie également l'état de somme de contrôle et de page endommagée, ainsi que l'ID de la page. Lorsqu'elle crée une somme de contrôle de sauvegarde, une opération de sauvegarde n'ajoute aucune somme de contrôle aux pages. Les pages sont sauvegardées telles qu'elles existent dans la base de données et ne sont pas modifiées par la sauvegarde. En raison de la charge inhérente à la vérification et à la génération des sommes de contrôle de sauvegarde, l'utilisation de ces sommes peut avoir des répercussions sur les performances. La charge de travail et le débit de sauvegarde peuvent être affectés. Par conséquent, l'utilisation de sommes de contrôle de sauvegarde est facultative. Lorsque vous décidez de générer des sommes de contrôle pendant une sauvegarde, surveillez attentivement la charge processeur induite, ainsi que l'impact sur les charges de travail simultanées du système.
[!REMARQUE]
L'instruction BACKUP ne modifie jamais la page source sur le disque, ni le contenu d'une page.
Les options BACKUP suivantes contrôlent le comportement des sommes de contrôle de sauvegarde :
CHECKSUM
L'opération de sauvegarde vérifie dans chaque page les informations de somme de contrôle et de page endommagée, si elles sont activées et disponibles, et génère une somme de contrôle pour l'ensemble de la sauvegarde.
Si une vérification de somme de contrôle est requise lors d'une opération de sauvegarde :
Avant d'écrire une page sur le support de sauvegarde, l'instruction BACKUP vérifie les informations de niveau page : somme de contrôle de page ou détection de page endommagée, si elles existent. En leur absence, la sauvegarde ne peut pas vérifier la page ; celle-ci est incluse telle quelle et le contenu est ajouté à la somme de contrôle de sauvegarde globale.
[!REMARQUE]
Pour plus d'informations sur les sommes de contrôle de page et sur la détection de page endommagée, consultez l'option PAGE_VERIFY de l'instruction ALTER DATABASE. Pour plus d'informations, consultez ALTER DATABASE (Transact-SQL).
Pour pouvoir l'utiliser lors de la restauration, la sauvegarde génère une somme de contrôle de sauvegarde séparée (somme de contrôle de sauvegarde) et l'enregistre sur le support de sauvegarde, que la somme de contrôle de la page soit disponible ou non.
Le jeu de sauvegarde est signalé comme contenant des sommes de contrôle de sauvegarde (dans la colonne has_backup_checksums de msdb..backupset). Pour plus d'informations, consultez backupset (Transact-SQL).
[!REMARQUE]
Dans le cas des sauvegardes de fichier journal, les sommes de contrôle de sauvegarde sont générées et vérifiées.
NO_CHECKSUM
Désactive explicitement la validation de page et la génération de sommes de contrôle de sauvegarde. (Il s'agit du comportement par défaut.)
Contrôle de la réponse à une erreur
Lorsque CHECKSUM est spécifié, la sauvegarde échoue si l'instruction BACKUP rencontre une erreur de page pendant la vérification. Les options de BACKUP suivantes contrôlent ce comportement :
CONTINUE_AFTER_ERROR
Indique à l'instruction BACKUP de continuer malgré la présence d'une somme de contrôle de sauvegarde non valide. Dans ce cas, l'instruction BACKUP :
Marque le jeu de sauvegarde sur le support de sauvegarde comme contenant des erreurs et trace la page dans la table suspect_pages de la base de données msdb. Pour plus d'informations, consultez suspect_pages (Transact-SQL).
Consigne l'erreur dans le journal des erreurs SQL Server.
Marque le jeu de sauvegarde comme contenant ce type d'erreur (dans la colonne is_damaged de msdb.backupset). Pour plus d'informations, consultez backupset (Transact-SQL).
Émet un message indiquant que la sauvegarde a été correctement générée, mais qu'elle contient des erreurs de page.
STOP_ON_ERROR
Indique à l'instruction BACKUP d'échouer en cas de non-validation d'une somme de contrôle. (Il s'agit du comportement par défaut.)
Sommes de contrôle pendant les opérations RESTORE et RESTORE VERIFYONLY
Si des sommes de contrôle de sauvegarde sont présentes sur le support de sauvegarde, par défaut, les opérations RESTORE et RESTORE VERIFYONLY vérifient les sommes de contrôle de sauvegarde et les sommes de contrôle de page. En l'absence de somme de contrôle de sauvegarde, les deux opérations de restauration se poursuivent sans vérification ; en effet, sans somme de contrôle de sauvegarde, la restauration ne peut pas vérifier les sommes de contrôle de page de façon fiable.
Deux options, en l'occurrence CHECKSUM et NO_CHECKSUM, vous permettent de modifier la façon dont les opérations RESTORE et RESTORE VERIFYONLY gèrent la vérification des sommes de contrôle :
CHECKSUM
Si vous spécifiez explicitement CHECKSUM pour une opération de restauration et que la sauvegarde contient des sommes de contrôle de sauvegarde, ces sommes de contrôle de sauvegarde ainsi que les sommes de contrôle de page sont vérifiées, comme dans le cas par défaut. Toutefois, si le jeu de sauvegarde manque de sommes de contrôle de sauvegarde, l'opération de restauration se solde par un échec et l'affichage d'un message indiquant l'absence des sommes de contrôle.
NO_CHECKSUM
Désactive explicitement la validation par défaut de toute somme de contrôle par l'opération de restauration.
Contrôle de la réponse à une erreur
Pour spécifier le comportement qu'une opération de restauration doit adopter en cas d'erreur, utilisez les options RESTORE et RESTORE VERIFYONLY suivantes :
CONTINUE_AFTER_ERROR
Spécifie que l'opération de restauration doit continuer en cas de détection d'une erreur. Il s'agit du comportement par défaut de RESTORE VERIFYONLY, ce qui lui permet d'indiquer les erreurs de validation, en fournissant autant d'informations que possible sur le jeu de sauvegarde, et de poursuivre l'opération. CONTINUE_AFTER_ERROR indique à RESTORE de continuer aussi bien que possible. Entre autres conséquences, RESTORE ignore la somme de contrôle non valide.
STOP_ON_ERROR
Spécifie que l'opération de restauration s'arrête et échoue à la première erreur rencontrée. Il s'agit du comportement par défaut de RESTORE.