Sauvegardes de fichier journal après défaillance

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 et que vous envisagez d'effectuer une opération de restauration de la base de données, avant de lancer l'opération de restauration, sauvegardez la fin du journal à l'aide de WITH NORECOVERY :

  BACKUP LOG nom_base_de_données TO <backup_device> WITH NORECOVERY

  [!REMARQUE]

  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 comme suit :

  BACKUP LOG nom_base_de_données TO <backup_device> WITH CONTINUE_AFTER_ERROR

  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. Important Nous vous recommandons d'éviter d'utiliser NO_TRUNCATE, sauf si la base de données est endommagée.
CONTINUE_AFTER_ERROR	Utilisez CONTINUE_AFTER_ERROR uniquement si vous sauvegardez la fin d'une base de données endommagée. Remarque 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

• Procédure : sauvegarde du journal des transactions lorsque la base de données est endommagée (Transact-SQL)

• Procédure : effectuer une sauvegarde de fichier journal de transactions après défaillance (SQL Server Management Studio)

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 :

• La restauration d'une base de données jusqu'à un point dans le temps contenu dans une sauvegarde précédente de journal.

  Une sauvegarde de fichier journal après défaillance n'est pas nécessaire si vous restaurez une base de données et spécifiez l'option STOPAT, STOPATMARK ou STOPBEFOREMARK dans chaque instruction RESTORE de votre séquence de restauration.

  Pour restaurer une base de données à un point antérieur dans le temps

  • Pour utiliser Transact-SQL pour restaurer à un point spécifique dans le temps, consultez Procédure : restaurer jusqu'à une date et heure (Transact-SQL), Récupération jusqu'à une transaction marquée, ou Récupération d'un numéro séquentiel dans le journal.

  • Pour utiliser SQL Server Management Studio, consultez Procédure : restaurer jusqu'à une limite dans le temps (SQL Server Management Studio) ou Procédure : restaurer une base de données jusqu'à une transaction marquée (SQL Server Management Studio).

• Restauration d'une copie d'une base de données dans un nouvel emplacement.

  Si vous restaurez une base de données, vous pouvez utiliser le même nom de base de données uniquement si vous restaurez la base de données sur une instance de serveur différente comme lorsque vous créez une base de données miroir pour une mise en miroir de base de données ou une base de données secondaire pour la copie des journaux de transactions. Si vous déplacez une base de données sur la même instance de serveur, vous devez spécifier un nouveau nom pour la base de données.

  Pour restaurer une base de données vers un nouvel emplacement

  • Spécifiez l'option MOVE dans chaque instruction RESTORE de votre séquence de restauration à l'aide de Transact-SQL. Pour plus d'informations, consultez Procédure : restaurer une base de données en utilisant un nouvel emplacement et un nouveau nom (Transact-SQL) ou Procédure : restauration de fichiers à un nouvel emplacement (Transact-SQL).

  • À l'aide de SQL Server Management Studio, spécifiez le nouvel emplacement de chaque fichier dans le champ Restaurer sous dans Restaurer la base de données (page Options). Pour plus d'informations, consultez Procédure : restaurer une sauvegarde de base de données (SQL Server Management Studio).

• Remplacement complet (écrasement) de la base de données.

  Attention
  La restauration à l'aide de l'option REPLACE doit être utilisée rarement et uniquement par des administrateurs de base de données expérimentés, après un examen attentif. Pour plus d'informations, consultez Utilisation de l'option REPLACE.

  Pour remplacer une base de données

  • À l'aide de Transact-SQL, spécifiez l'option REPLACE dans vos instructions RESTORE.

  • À l'aide de SQL Server Management Studio, spécifiez le nouvel emplacement de chaque fichier dans le champ Restaurer sous dans Restaurer la base de données (page Options). Pour plus d'informations, consultez Procédure : restaurer une sauvegarde de base de données (SQL Server Management Studio).

Voir aussi

Référence

Concepts

Historique des modifications