Sauvegardes de fichier journal après défaillance

Mis à jour : 17 juillet 2006

Icône présentant un disque de base de données bleue Cette rubrique s'applique uniquement aux bases de données employant les modes de restauration complète ou de récupération utilisant les journaux de transactions.

Dans la plupart des cas, en mode de restauration complète ou en mode de récupération utilisant les journaux de transactions, SQL Server 2005 exige que vous sauvegardiez la fin du journal pour capturer les enregistrements de journal qui n'ont pas encore été sauvegardés. Une sauvegarde de la fin du journal effectuée juste avant une opération de restauration s'appelle une sauvegarde de fichier journal après défaillance.

SQL Server 2005 nécessite habituellement d'effectuer une sauvegarde de fichier journal après défaillance avant de commencer à restaurer une base de données. Une sauvegarde de fichier journal après défaillance empêche la perte de données et préserve la continuité de la séquence de journaux de transactions consécutifs. Si vous récupérez une base de données jusqu'à la défaillance, la sauvegarde de fichier journal après défaillance est la dernière sauvegarde pertinente du plan de récupération. Si vous ne pouvez pas effectuer la sauvegarde de fin de journal, vous pouvez récupérer une base de données uniquement jusqu'à la fin de la dernière sauvegarde ayant été créée avant la défaillance.

Tous les scénarios de restauration ne nécessitent pas une sauvegarde de fichier journal après défaillance. Vous n'êtes pas obligé de disposer d'une sauvegarde de fichier journal après défaillance si le point de récupération est contenu dans une sauvegarde de journal antérieure ou si vous déplacez ou remplacez (par écrasement) la base de données. De plus, si les fichiers journaux sont endommagés et une sauvegarde de fichier journal après défaillance ne peut pas être créée, vous devez restaurer la base de données sans utiliser une sauvegarde de fichier journal après défaillance. Les transactions validées après la dernière sauvegarde de journal sont perdues. Pour plus d'informations, consultez « Restauration sans utiliser de sauvegarde de fichier journal après défaillance » plus loin dans cette rubrique.

Sauvegarde de la fin du journal

Comme toute sauvegarde de journal, une sauvegarde de fichier journal après défaillance s'effectue à l'aide de l'instruction BACKUP LOG. Nous vous recommandons d'effectuer une sauvegarde de fichier journal après défaillance dans les situations suivantes :

  • Si la base de données est en ligne, avant de lancer une séquence de restauration, sauvegardez la fin du journal à l'aide de WITH NORECOVERY à chaque fois que vous envisagez d'effectuer une opération de sauvegarde de la base de données :
    BACKUP LOG database_name TO <backup_device> WITH NORECOVERY
    ms179314.note(fr-fr,SQL.90).gifRemarque :
    Pour éviter une erreur, l'option NORECOVERY est nécessaire.
  • Si la base de données est hors connexion et ne démarre pas.
    Essayez d'effectuer une sauvegarde de fichier journal après défaillance. Comme il est exclu d'effectuer une transaction à ce stade, l'utilisation de WITH NORECOVERY est facultative. Si la base de données est endommagée, utilisez WITH CONTINUE_AFTER_ERROR ou WITH NO_TRUNCATE.
    BACKUP LOG database_name TO <backup_device> [WITH { CONTINUE_AFTER_ERROR | NO_TRUNCATE }
    ms179314.note(fr-fr,SQL.90).gifImportant :
    Nous vous recommandons d'éviter d'utiliser NO_TRUNCATE, sauf si la base de données est endommagée.
    Si la base de données est endommagée, par exemple, ou si elle ne démarre pas, une sauvegarde de fichier journal après défaillance n'aboutit que si les fichiers journaux ne sont pas endommagés, la base de données est en mesure de prendre en charge cette sauvegarde de fichier journal après défaillance, et la base de données ne contient pas de modifications journalisées en bloc.

Ces options sont résumées dans le tableau ci-dessous.

Option BACKUP LOG

Commentaires

NORECOVERY

Utilisez NORECOVERY chaque fois que vous envisagez de poursuivre une opération de restauration sur la base de données. NORECOVERY fait passer la base de données en état de restauration. Ceci permet d'éviter des modifications dans la base de données après la sauvegarde de fichier journal après défaillance.

Le journal est tronqué sauf si l'option NO_TRUNCATE ou COPY_ONLY est aussi spécifiée.

{ CONTINUE_AFTER_ERROR | NO_TRUNCATE }

Utilisez NO_TRUNCATE ou CONTINUE_AFTER_ERROR uniquement si vous sauvegardez la fin d'une base de données endommagée.

ms179314.note(fr-fr,SQL.90).gifRemarque :

Si vous sauvegardez la fin du journal sur une base de données endommagée, certaines métadonnées capturées normalement dans des sauvegardes de journaux sont parfois indisponibles. Pour plus d'informations, consultez « Sauvegardes de fichier journal après défaillance avec des métadonnées de sauvegarde incomplètes », plus loin dans cette rubrique.

Pour créer une sauvegarde du journal des transactions lorsque la base de données est endommagée

Sauvegardes de fichier journal après défaillance avec des métadonnées de sauvegarde incomplètes

Les sauvegardes de fichier journal après défaillance capturent la fin du journal même si la base de données est hors connexion ou endommagée, ou s'il y manque des fichiers de données. Cela peut aboutir à des métadonnées incomplètes à partir des commandes d'informations de restauration et de msdb. Mais seules les métadonnées sont incomplètes ; le journal capturé est complet et exploitable.

Si une sauvegarde de fichier journal après défaillance contient des métadonnées incomplètes, dans la table backupset, has_incomplete_metadata est défini sur 1. De plus, dans le résultat de RESTORE HEADERONLY, HasIncompleteMetadata a la valeur 1.

Si les métadonnées d'une sauvegarde de fichier journal après défaillance sont incomplètes, la table backupfilegroup est absente de la plupart des informations relatives aux groupes de fichiers au moment de la sauvegarde de fichier journal après défaillance. La plupart des colonnes de la table backupfilegroup ont la valeur NULL ; seules les colonnes suivantes ont une signification :

  • backup_set_id
  • filegroup_id
  • type
  • type_desc
  • is_readonly

Restauration sans utiliser de sauvegarde de fichier journal après défaillance

Les scénarios de restauration qui ne nécessitent pas de sauvegarde de fichier journal après défaillance sont les suivants :

Voir aussi

Concepts

Sauvegardes de type copie seule
États d'une base de données
Application de sauvegardes du journal des transactions
Création de sauvegardes des fichiers journaux de transactions

Autres ressources

BACKUP (Transact-SQL)

Aide et Informations

Assistance sur SQL Server 2005

Historique des modifications

Version Historique

17 juillet 2006

Nouveau contenu :
  • Les explications relatives au contournement de la sauvegarde de fichier journal après défaillance ont été développées dans une section séparée « Restauration sans utiliser de sauvegarde de fichier journal après défaillance ».
Contenu modifié :
  • Mise à jour de la section « Sauvegarde de la fin du journal ».