Numéros de séquence d'enregistrement et planification de la restauration

 Cette rubrique s'applique aux bases de données SQL Server employant le mode de restauration complète.

Pour la planification de la restauration, les numéros de séquences d'enregistrement (NSE) les plus importants sont le premier et le dernier. Ces NSE peuvent provenir des emplacements suivants :

• La table backupset de la base de données msdb. Les colonnes sont intitulées first_lsn et last_lsn.
• L'instruction RESTORE HEADERONLY. Les colonnes sont intitulées FirstLSN et LastLSN.

Le tableau suivant définit ces termes pour différentes sauvegardes.

Terme	Définition
first_lsn ou FirstLSN	Numéro de séquence d'enregistrement correspondant au premier ou plus ancien enregistrement du journal dans le jeu de sauvegarde Pour les sauvegardes de données et différentielles, le premier NSE identifie l'enregistrement le plus ancien du journal nécessaire pour effectuer la récupération avec cette sauvegarde. Pour les sauvegardes de fichier journal, le premier NSE identifie le premier enregistrement du journal inclus dans la sauvegarde.
last_lsn ou LastLSN	Numéro de séquence d'enregistrement correspondant à l'enregistrement suivant après le jeu de sauvegarde Le dernier NSE identifie l'enregistrement suivant du journal au-delà de la fin de la sauvegarde. Pour les sauvegardes de données et différentielles (et pour les sauvegardes de fichier journal contenant des opérations journalisées en bloc), la restauration par progression doit au moins atteindre ce NSE. Sinon, les données copiées pendant la restauration ne sont pas cohérentes. Quant aux sauvegardes de fichier journal, elles contiennent les enregistrements du journal jusqu'à ce NSE, sans toutefois l'inclure.

Numéros de séquences d'enregistrement et sauvegardes de données ou différentielles

Pour la sauvegarde de données et différentielles, les données du journal comprises entre first_lsn et last_lsn sont incluses dans la sauvegarde. La sauvegarde peut ainsi être utilisée sans sauvegardes de fichier journal pour effectuer une récupération jusqu'à last_lsn.

Pour une sauvegarde de données ou différentielle, last_lsn est le point de récupération le plus ancien possible si vous utilisez la sauvegarde dans une séquence de restauration. Si un point de récupération antérieur est nécessaire, une sauvegarde antérieure doit être utilisée.

Si vous planifiez la sauvegarde de fichier journal à utiliser pour effectuer une restauration par progression après la restauration d'une sauvegarde de données ou différentielle, vous commencez en général par la première sauvegarde de fichier journal après cette sauvegarde de données ou différentielle. Lorsque vous examinez les propriétés de la sauvegarde, vous allez trouver une sauvegarde de fichier journal dont le NSE first_lsn est inférieur ou égal au NSE last_lsn de la sauvegarde de données ou différentielle et dont le NSE last_lsn est strictement supérieur au NSE last_lsn de la sauvegarde de données ou différentielle.

Numéros de séquences d'enregistrement et sauvegardes de fichier journal dans une séquence de journaux de transactions consécutifs

Une nouvelle séquence de journaux de transactions consécutifs débute avec la première sauvegarde complète après la création de la base de données ou après avoir basculé du mode de récupération simple au mode de restauration complète ou de récupération utilisant les journaux de transactions. Dans la première sauvegarde de fichier journal d'une séquence, backupset.begins_log_chain = 1.

Les NSE first_lsn et last_lsn servent à lier les sauvegardes de fichier journal en une séquence de journaux consécutifs. Vous pouvez utiliser une séquence de sauvegardes de fichier journal consécutives pour restaurer par progression une base de données soit à partir de la sauvegarde de données ou différentielle la plus récente, soit à partir d'une sauvegarde antérieure après des sauvegardes de données et différentielles manquantes ou endommagées.

Dans une sauvegarde de fichier journal, first_lsn est le NSE du premier enregistrement du journal dans la sauvegarde ; en commençant par lui, la sauvegarde de fichier journal inclut les enregistrements du journal jusqu'à celui dont le NSE est last_lsn, ce dernier NSE étant exclu. Deux sauvegardes de fichier journal sont consécutives si et seulement si le NSE du dernier enregistrement de journal de la sauvegarde antérieure (Backup_A) est supérieur ou égal au NSE du premier enregistrement du journal de la sauvegarde plus tardive (Backup_B) ; en d'autres termes, Backup_A.last_lsn >= Backup_B.first_lsn. Si cette condition n'est pas satisfaite, il existe une rupture entre les deux sauvegardes.

La signification de la relation entre ces NSE est la suivante :

• A.last_lsn = B.first_lsn
  Si A.last_lsn = B.first_lsn, B est habituellement la sauvegarde de fichier journal effectuée immédiatement après A.
  Cette relation est illustrée dans la figure ci-dessous. Notez que l'enregistrement de journal n, qui a lieu dans la sauvegarde de journal B, a été enregistrée en temps que last_lsn dans la sauvegarde de journal A et en tant que first_lsn dans la sauvegarde de journal B.
  
• A.last_lsn > B.first_lsn
  Si A.last_lsn > B.first_lsn, il existe un chevauchement. Un chevauchement est généralement la conséquence de la création d'une sauvegarde de fichier journal en copie uniquement ou de la première sauvegarde de journal effectuée après une récupération dans le temps. Le chevauchement peut concerner plusieurs branchements de récupération. Pour plus d'informations, consultez Chemins de récupération.

Causes de rupture de séquences de journaux de transactions consécutifs

En général, le moteur de base de données SQL Server évite les ruptures dans la séquence des sauvegardes de fichier journal, préservant ainsi la continuité de la séquence de journaux de transactions consécutifs. Toutefois, un administrateur de base de données peut rompre la séquence de journaux de transactions consécutifs en passant au mode de récupération simple et en revenant au mode de restauration complète ou de récupération utilisant les journaux de transactions.

Vous ne pouvez pas effectuer de restauration par progression si un changement de mode de récupération implique le mode de récupération simple, car la séquence de journaux de transactions consécutifs est rompue. Après être passé au mode de restauration complète ou de récupération utilisant les journaux de transactions, vous devez effectuer une nouvelle base différentielle ou un nouveau jeu de bases différentielles. D'une autre manière, vous pouvez utiliser les sauvegardes différentielles pour combler une rupture.

Voir aussi

Concepts

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)
Visualisation des informations concernant les sauvegardes
Récupération d'un numéro de séquence d'enregistrement (NSE)
Chemins de récupération
Architecture logique du journal des transactions

Autres ressources

backupset (Transact-SQL)
RESTORE HEADERONLY (Transact-SQL)

Aide et Informations

Assistance sur SQL Server 2005