Chemins de récupération

La compréhension des chemins de récupération est importante si vous effectuez des sauvegardes différentielles ou des sauvegardes de journaux et que vous procédez à la récupération d'une base de données jusqu'à une limite antérieure dans le temps selon une des méthodes suivantes :

• Restauration limitée dans le temps
• Une restauration, sans restaurer au préalable toutes les sauvegardes de journaux ou les sauvegardes différentielles les plus récentes.

Si vous récupérez une base de données à partir d'un point de récupération antérieur et que vous commencez à utiliser la base de données à partir de ce point, un nouveau chemin de récupération est initialisé. Le chemin de récupération représente la séquence des sauvegardes des données et des journaux qui ont amené une base de données à un moment particulier, que cela soit via un usage régulier de la base de données ou via une restauration spécifique de données et de journaux. Un chemin de récupération est constitué d'un jeu unique de transformations particulières qui ont fait évoluer la base de données au cours du temps, tout en maintenant sa cohérence. L'illustration suivante montre les relations existantes entre un point de récupération et les chemins de récupération résultants.

En général, un point de récupération initialise un nouveau chemin de récupération, dans la mesure où les transactions doivent être restaurées et où la base de données se trouve maintenant dans un état unique. Les sauvegardes antérieures peuvent désormais avoir des NSE supérieurs au NSE du point de récupération. Ces NSE se situent sur une branche de récupération différente de la nouvelle branche créée par le point de récupération actuel.

Remarque :
La restauration d’une sauvegarde complète de la base de données et la récupération de la base de données sans utilisation d'un autre type de sauvegarde donnent lieu à un nouveau chemin de récupération.

Meilleure pratique Pour éviter de créer un chemin de récupération à plusieurs branchements de récupération, effectuez un jeu complet de sauvegardes des données dès que possible, après la récupération de la base de données. Cette méthode garantit que toutes les sauvegardes ont lieu sur une branche de récupération unique. Pour vérifier cette méthode, consultez la colonne last_recovery_fork_guid dans la table backupset ou le jeu de résultats RESTORE HEADERONLY.

Les situations suivantes créent un nouveau chemin de récupération car la base de données n'est pas restaurée « jusqu'à la fin du temps ». Ensuite, les sauvegardes existantes peuvent faire descendre la base de données dans au moins deux chemins de récupération qui utilisent tous le même éventail de NSE.

• La restauration d'une sauvegarde complète et une sauvegarde différentielle de la base de données, ainsi que sa récupération sans l'application des sauvegardes des journaux de transactions existants.
• La récupération de la base de données à la fin d’une sauvegarde différentielle différente de celle la plus récente.
• La récupération de la base de données à la fin d’une sauvegarde du journal des transactions différente de la plus récente.
• La récupération de la base de données à un moment spécifique ou au niveau d'une transaction marquée au sein d’une sauvegarde du journal des transactions.

Exemple de chemin de récupération

L'illustration suivante montre le branchement d'un nouveau chemin de récupération une fois la base de données récupérée. Dans cette illustration, une sauvegarde complète de la base de données et une succession de quatre sauvegardes du journal sont créées. La base de données est ensuite restaurée jusqu'à la fin de la Sauvegarde de journal 2 en restaurant la sauvegarde complète de la base de données, la Sauvegarde de journal 1, et la Sauvegarde de journal 2. La base de données est récupérée à partir de ce point, ce qui génère un nouveau branchement de récupération. La base de données est ensuite utilisée pour une période, et deux sauvegardes de journal supplémentaires sont créées, Sauvegarde de journal 5 et Sauvegarde de journal 6.

La sauvegarde de base de données et les quatre premières sauvegardes de journaux figurent toutes sur le branchement 1. La Sauvegarde de journal 5 et la Sauvegarde de journal 6 sont sur le branchement 2. Le branchement de récupération contient le dernier NSE de la Sauvegarde de journal 2 (Log_Backup_2.LastLSN) et le premier NSE de la Sauvegarde de journal 5 (Log_Backup_5.FirstLSN).

Dans la Sauvegarde de journal 5, first_recovery_fork_guid identifie le branchement 1, et last_recovery_fork_guid identifie le branchement 2. Le chemin de récupération est le branchement 1, le branchement 2.

Remarque :
La restauration à la fin d'une sauvegarde de journal n'est pas requise pour effectuer un branchement vers un nouveau chemin.

Pour restaurer et restaurer par progression dans le cadre d'un ancien chemin

Nous vous recommandons d'éviter l'utilisation d'un ancien chemin de récupération. Son utilisation peut entraîner la présence dans la base de données de transactions validées dans deux intervalles de temps différents. Cependant, si nécessaire, vous pouvez restaurer par progression sur un ancien chemin de récupération en suivant la séquence des sauvegardes effectuées avant la création du chemin de récupération actuel. Par exemple, vous pouvez utiliser les sauvegardes réalisées avant une récupération à un point précis dans le temps, dans le cadre de l'ancien chemin.

Remarque :
Pour créer deux bases de données à partir d'un parent commun, pour chaque base de données, examinez le chemin de récupération à utiliser pour atteindre la fin de cette base de données.

Par exemple, en fonction des sauvegardes créées dans l'illustration précédente, après la création de la Sauvegarde de journal 5 et la Sauvegarde de journal 6, il est toujours possible de restaurer jusqu'à la fin de la Sauvegarde de journal 3 qui se trouve sur l'ancien chemin de récupération.

Pour restaurer et restaurer par progression à partir d'un ancien chemin vers un nouveau chemin

Le moteur de base de données SQL Server empêche une séquence de restauration unique d'utiliser des sauvegardes non compatibles entre elles, et de ce fait, qui tentent de restaurer par progression dans le cadre de chemins de récupération différents. Cette restriction maintient la cohérence de la base de données après une récupération.

Pour restaurer et restaurer par progression dans le cadre d'un nouveau chemin de récupération, créez des séquences de restauration distinctes pour les sauvegardes, avant et après le point de récupération :

1. Restaurez les sauvegardes effectuées avant la récupération qui a engendré le nouveau chemin de récupération. Excluez la sauvegarde contenant le point de récupération.
2. Restaurez par progression dans le cadre du nouveau chemin de récupération en restaurant les sauvegardes effectuées depuis la création du chemin de récupération.

Par exemple, en fonction des sauvegardes créées dans l'illustration précédente, supposons que la Sauvegarde de journal 3 corresponde à la plage horaire de 10h00 à 11h00. Une restauration limitée dans le temps a eu lieu et spécifie STOPAT**=10:**30. Cette opération a créé un branchement dans le chemin de récupération ainsi qu'un nouveau branchement de récupération. Branchement 2. La première sauvegarde des journaux sur le nouveau branchement, la Sauvegarde de journal 5, contient le même premier NSE que la Sauvegarde de journal 3, qui remplace la Sauvegarde de journal 3, désormais obsolète. Pour restaurer les sauvegardes sur le nouveau chemin de récupération (en commençant au branchement 1 et en terminant au branchement 2), la séquence de restauration est la suivante : Sauvegarde complète de la base de données, Sauvegarde de journal 1, Sauvegarde de journal 2, Sauvegarde de journal 5 et Sauvegarde de journal 6

Gestion des branchements de récupération

Une branche de récupération correspond à un éventail de NSE qui partage le même GUID (identifiant global unique). Un chemin de récupération décrit un éventail de NSE entre un point de départ (NSE,GUID) et un point final (NSE,GUID). Le jeu de NSE d'un chemin de récupération peut traverser une ou plusieurs branches de récupération entre le début et la fin. Une nouvelle branche de récupération est initialisée lorsqu'une base de données est créée et lorsque RESTORE WITH RECOVERY génère un branchement de récupération.

Un branchement de récupération correspond au point (NSE,GUID) à partir duquel une nouvelle branche de récupération s'initialise chaque fois qu'un RESTORE WITH RECOVERY est exécuté. Chaque branchement de récupération établit une relation de type parent/enfant entre les branches de récupération.

La récupération de la base de données définit l'état global de celle-ci, y compris le prochain NSE, au point de récupération. Les NSE sont ensuite réutilisés, en commençant par le fork_point_lsn. Par conséquent, lors de l'établissement d'une séquence de restauration, les sauvegardes doivent être reliées par branchement de récupération, ainsi que par NSE, dans la mesure où le même NSE peut exister dans plus d'un branchement. L'illustration ci-dessous montre la réutilisation du NSE. Elle illustre la réutilisation des NSE dans différents branchements de récupération.

Si une séquence de restauration doit incorporer des sauvegardes traversant un branchement de récupération, elle doit être construite de manière à ce que les sauvegardes utilisées suivent le chemin de récupération correct jusqu'au point de récupération. Les sauvegardes incluent les paramètres backupset.first_recovery_fork_guid et backupset.last_recovery_fork_guid à cet effet. Ils sont utilisés pour relier les sauvegardes, afin de s'assurer que la séquence suit le branchement correct.

Les valeurs de la table d'historique backupset vous permettent de déterminer quel jeu de sauvegardes utiliser :

• Pour chaque sauvegarde de journal de la séquence à restaurer, le paramètre first_recovery_fork_guid doit être égal au paramètre last_recovery_fork_guid de la sauvegarde précédente de la séquence.
  
• Les sauvegardes de données et différentielles doivent également être liées.
  Si la sauvegarde de journal contient à la fois le dernier NSE d'une sauvegarde de base de données complète ou d'une sauvegarde de base de données différentielle et d'un point de branchement, le test de liaison dépend de l'emplacement du dernier NSE par rapport au point de branchement.
  Les tests de liaison sont les suivants et reposent sur les valeurs de backupset :
  • Si last_lsn est inférieur ou égal à fork_point_lsn, le paramètre last_recovery_fork_guid de la sauvegarde de données ou de la sauvegarde différentielle doit être égal au paramètre first_recovery_fork_guid de la sauvegarde de journal. L'illustration suivante montre une situation au cours de laquelle last_lsn est inférieur à fork_point_lsn.
    
  • Si last_lsn est supérieur à fork_point_lsn, le paramètre last_recovery_fork_guid de la sauvegarde de données ou de la sauvegarde différentielle doit être égal au paramètre first_recovery_fork_guid de la sauvegarde de journal. L'illustration suivante montre une situation au cours de laquelle last_lsn est supérieur à fork_point_lsn.
    
• Pour une sauvegarde différentielle, recherchez la base différentielle en utilisant backupset.differential_base_guid.
  Si la base de la sauvegarde différentielle est multiple, backupset.differential_base_guid est NULL, et vous devez déterminer les bases différentielles fichier par fichier en utilisant backupfile.differential_base_guid.

Voir aussi

Concepts

Copie de bases de données avec la sauvegarde et la restauration
Planification et exécution des séquences de restauration (mode de restauration complète)
Présentation des numéros de séquence d'enregistrement (LSN)
Numéros de séquence d'enregistrement et planification de la restauration
Base d'une sauvegarde différentielle

Autres ressources

Implémentation de scénarios de restauration pour les bases de données SQL Server

Aide et Informations

Assistance sur SQL Server 2005