Planification d'une séquence de restauration fragmentaire pour un fichier dans l'état de restauration, de récupération en attente ou hors connexion

 Cette rubrique ne s'applique qu'aux bases de données SQL Server contenant plusieurs groupes de fichiers (et, en mode de récupération simple, uniquement des groupes de fichiers en lecture seule) lorsque vous planifiez une récupération fragmentaire d'une base de données.

Si une séquence de restauration concerne un fichier dans l'état de restauration, de récupération en attente ou hors connexion, vous pourrez sans doute récupérer ce fichier sans restaurer ses données. Pour déterminer si vous devez restaurer une sauvegarde complète du fichier ou si vous pouvez simplement récupérer le fichier, vous pouvez faire appel aux métadonnées stockées dans les affichages catalogue sys.database_files et sys.master_files.

NSE de restauration

La première étape consiste à inspecter les colonnes d'affichage catalogue qui contiennent les NSE de restauration : redo_start_lsn, redo_start_fork_guid, redo_target_lsn, et redo_target_fork_guid. Le tableau suivant décrit les NSE de restauration et explique comment les interpréter.

Colonnes

Description

redo_start_lsn et redo_start_fork_guid

Ensemble, ces colonnes décrivent une paire (lsn,guid) qui représente le point chronologique du fichier. Au fil de la restauration par progression du fichier, les valeurs de ces colonnes changent. La restauration par progression se poursuit à partir de cette limite dans le temps.

ImportantImportant
Si redo_start_lsn = NULL, l'état du fichier sur le disque est inconnu, et celui-ci doit être restauré à partir d'une sauvegarde complète.

redo_target_lsn et redo_target_fork_guid

Ensemble, ces colonnes décrivent une paire (lsn,guid) définissant le point de récupération jusqu'où le fichier doit être restauré pour qu'il soit cohérent avec la base de données en ligne (le point de récupération cible).

Choix de l'utilisation des affichages sys.database_files ou sys.master_files

Les affichages catalogue sys.database_files et sys.master_files contiennent les colonnes de NSE de restauration, ces affichages ne sont toutefois pas toujours cohérents. En général, si la base de données est en ligne, les valeurs dans les affichages catalogue sys.database_files et sys.master_files sont cohérentes. Cependant, les valeurs seront incohérentes dans les situations suivantes :

  • Si la base de données est en lecture seule, sys.database_files n'est pas mis à jour avec les modifications découlant de la sauvegarde et seul sys.master_files contient des informations à jour.

    [!REMARQUE]

    Pour déterminer si un fichier est en lecture seule, examinez le contenu des colonnes is_read_only et read_only_lsn. is_read_only indique si le fichier est en lecture seule. si tel est le cas, read_only_lsn indique le point à partir duquel il l'est devenu.

  • Si la base de données est hors connexion (par exemple, pendant sa restauration), le catalogue de base de données est inaccessible. Pour une base de données hors connexion, vous devez utiliser sys.master_files pour obtenir des informations.

  • Si une opération de restauration affecte actuellement le fichier, les NSE de restauration du fichier sont en cours de mise à jour et sont incohérents. N'examinez les colonnes de NSE de restauration qu'entre les restaurations.

Interprétation des valeurs de ces colonnes

[!REMARQUE]

Cette section suppose votre maîtrise des concepts de chemin de récupération et de branchement de récupération. Pour plus d'informations, consultez Chemins de récupération.

Cette section ne s'applique que si vous avez effectué une récupération dans le temps et que vous disposez toujours de sauvegardes issues de chemins de récupération obsolètes. Si vous restaurez un fichier dans l'état de restauration, de récupération en attente ou hors connexion, les branchements de récupération s'appliquent. Vous pouvez identifier les chemins de récupération potentiels en analysant les branchements de récupération. Généralement, il existe un chemin de récupération qui convient le mieux à la récupération de la base de données.

Pour identifier ce chemin, vous devez déterminer si le fichier se trouve sur le branchement de récupération cible ou sur un branchement de récupération différent :

  • Le fichier se trouve dans un autre branchement de récupération.

    Si redo_start_fork_guid != redo_target_fork_guid et n'est pas un ancêtre de redo_target_fork_guid, le fichier se trouve dans un branchement différent du branchement cible.

    [!REMARQUE]

    Pour rechercher un branchement ancêtre, suivez la séquence de journaux dans le sens contraire. Pour plus d'informations, consultez Chemins de récupération.

    Dans ce cas, le fichier doit être restauré à partir d'une sauvegarde complète. Cette restauration rétablit le fichier à un point constituant un ancêtre valide du point de récupération actif de la base de données.

    [!REMARQUE]

    Pour restaurer un fichier quel qu'il soit, sa sauvegarde doit être un ancêtre du point de récupération de la base de données. Recherchez toujours la sauvegarde complète du fichier la plus récente. Les données doivent être restaurées par progression jusqu'au point cible. Seule exception à cette règle : une sauvegarde d'un fichier en lecture seule ne doit pas forcément être restaurée par progression si le fichier était déjà en lecture seule avant la sauvegarde. Si nécessaire, après la restauration de la sauvegarde de fichiers, restaurez une sauvegarde de fichiers différentielle et, éventuellement, les sauvegardes des journaux pour atteindre le point de récupération cible.

  • Le fichier se trouve dans le branchement (cible) actif ou est un ancêtre du branchement cible.

    [!REMARQUE]

    Si vous avez sauvegardé le fichier depuis la récupération de la base de données, il se trouve dans le branchement de récupération cible.

    Dans ces cas de figure, la nécessité ou non de restaurer le fichier dépend de la relation entre redo_start_lsn et redo_target_lsn (voir tableau ci-dessous).

    Condition

    Conséquence

    redo_start_lsn =redo_target_lsn

    Il n'est pas nécessaire de restaurer le fichier.

    Le fichier est cohérent avec la base de données et peut être mis en ligne sans utiliser RESTORE DATABASE database_name WITH RECOVERY.

    redo_start_lsn <redo_target_lsn

    Pour pouvoir mettre le fichier en ligne, la restauration par progression doit atteindre le point redo_target_lsn.

    redo_start_lsn >redo_target_lsn

    La base de données est antérieure au fichier. Ce dernier doit être restauré à partir d'une sauvegarde complète (ou la base de données peut être à nouveau restaurée jusqu'à une limite ultérieure dans le temps avec une autre séquence de restauration partielle).

    RemarqueRemarque
    Cette situation peut se produire uniquement lors d'une restauration hors connexion, car dès que le groupe de fichiers primaire a été récupéré, un nouveau branchement de récupération est généré. Aucun groupe de fichiers secondaire non récupéré ne se trouvera plus sur le même chemin de récupération que le groupe de fichiers primaire.

[!REMARQUE]

Après avoir restauré les sauvegardes pour un de ces chemins de récupération, les autres chemins ne sont plus valides. Les sauvegardes spécifiques à un chemin de récupération non valide sont obsolètes. Il est recommandé de supprimer les sauvegardes obsolètes ou de les mettre de côté et des les marquer clairement comme obsolètes.