Vue d’ensemble de la restauration et de la récupération (SQL Server)

S'applique à :SQL Server

Cet article fournit une vue d'ensemble du processus de restauration et de récupération de la base de données pour SQL Server.

Overview

Pour récupérer une base de données SQL Server suite à une erreur, un administrateur de base de données doit restaurer un jeu de sauvegardes SQL Server dans une séquence de restauration correcte du point de vue logique et explicite. Le processus de restauration et de récupération SQL Server prend en charge la restauration des données à partir de sauvegardes d’une base de données entière, d’un fichier de données ou d’une page de données, comme suit :

  • La base de données ( restauration de base de données complète)

    La base de données complète est restaurée et récupérée, et la base de données est hors connexion pendant les opérations de restauration et de récupération.

  • Le fichier de données ( restauration de fichiers)

    Un fichier de données ou un ensemble de fichiers est restauré et récupéré. Au cours d’une restauration de fichiers, les groupes de fichiers contenant les fichiers sont mis automatiquement hors connexion pendant la restauration. Toute tentative d'accès à un groupe de fichiers hors connexion produit une erreur.

  • La page de données ( restauration de pages)

    Avec le mode de récupération complète ou le mode de récupération en masse, vous pouvez restaurer des pages individuelles. La restauration des pages peut être effectuée pour n'importe quelle base de données, quel que soit le nombre de groupes de fichiers.

La sauvegarde et la restauration SQL Server fonctionnent sur tous les systèmes d’exploitation pris en charge. Pour plus d’informations sur les systèmes d’exploitation pris en charge, consultez configuration matérielle et logicielle requise. Pour plus d’informations sur la prise en charge des sauvegardes à partir de versions antérieures de SQL Server, consultez la section Prise en charge de la compatibilité de RESTORE.

Scénarios de restauration

Un scénario de restauration dans SQL Server est le processus de restauration des données à partir d’une ou de plusieurs sauvegardes, puis de récupération de la base de données. Les scénarios de restauration pris en charge dépendent du mode de récupération de la base de données et de l’édition de SQL Server.

Le tableau suivant présente les scénarios de restauration possibles pris en charge pour différents modes de récupération.

Scénario de restauration En mode de récupération simple Sous les modèles de récupération Complets/à journalisation en bloc
restauration de base de données complète Stratégie de restauration de base. Une restauration complète de base de données peut impliquer simplement la restauration et la récupération d'une sauvegarde complète de base de données. Une restauration complète de base de données peut également impliquer la restauration d'une sauvegarde complète de base de données suivie de la restauration et de la récupération d'une sauvegarde différentielle.

Pour plus d’informations, consultez Restaurations complètes de bases de données (mode de récupération simple).		 Stratégie de restauration de base. Une restauration complète de base de données inclut la restauration d'une sauvegarde complète, et éventuellement d'une sauvegarde différentielle (le cas échéant), suivie par la restauration de toutes les sauvegardes de journal consécutives (en séquence). La restauration complète de la base de données s’achève en récupérant la dernière sauvegarde du journal des transactions, puis en la restaurant (RESTORE WITH RECOVERY).
Pour plus d’informations, consultez Restaurations complètes de bases de données (mode de récupération complète).
Restauration de fichiers 1 Restaure un ou plusieurs fichiers endommagés en lecture seule, sans restaurer toute la base de données. La restauration de fichiers est uniquement disponible si la base de données comporte au moins un groupe de fichiers en lecture seule. Restaure un ou plusieurs fichiers, sans restaurer la totalité de la base de données. La restauration de fichiers peut être effectuée lorsque la base de données est hors connexion ou, pour certaines éditions de SQL Server, alors que la base de données reste en ligne. Pendant une restauration de fichiers, les groupes de fichiers contenant les fichiers à restaurer restent toujours hors connexion.
Restauration de pages Sans objet Restaure une ou plusieurs pages endommagées. La restauration de pages peut être effectuée lorsque la base de données est hors connexion ou, pour certaines éditions de SQL Server, alors que la base de données reste en ligne. Pendant une restauration de pages, les pages en cours de restauration restent toujours hors connexion.

Une chaîne ininterrompue de sauvegardes de journaux doit être disponible, jusqu'au fichier journal actuel, et elles doivent toutes être appliquées pour mettre la page à jour par rapport au fichier journal actuel.
Pour plus d’informations, consultez l’article Restaurer des pages (SQL Server).
Restauration partielle 1 Restaure et récupère la base de données par phases au niveau du groupe de fichiers, en commençant par les groupes de fichiers primaires et tous les groupes de fichiers secondaires en lecture-écriture. Restaure et récupère la base de données par étapes au niveau du groupe de fichiers, en commençant par le groupe de fichiers primaire.

Pour plus d’informations, consultez Restaurations fragmentaires (SQL Server)

1 La restauration en ligne est prise en charge uniquement dans l’édition Enterprise.

Étapes de restauration d’une base de données

Pour effectuer une restauration de fichiers, le moteur de base de données exécute deux étapes :

  • Crée les fichiers de base de données manquants.

  • Copie les données des périphériques de sauvegarde vers les fichiers de base de données.

Pour effectuer une restauration de base de données, le moteur de base de données exécute trois étapes :

  • Création des fichiers de base de données et du journal des transactions s’ils n’existent pas déjà.

  • Copie de toutes les données, du journal et des pages d'index des supports de sauvegarde d'une base de données vers les fichiers de base de données.

  • Application du journal des transactions dans ce qui est connu sous le nom de processus de récupération.

Indépendamment du mode de restauration des données, avant de pouvoir récupérer une base de données, le moteur de base de données SQL Server garantit la cohérence logique de l’intégralité de la base de données. Par exemple, si vous restaurez un fichier, vous ne pouvez pas le récupérer et le mettre en ligne tant qu’il n’est pas suffisamment avancé pour être cohérent avec la base de données.

Avantages de la restauration d’un fichier ou d’une page

Restaurer et récupérer des fichiers ou des pages plutôt que la base de données entière offre plusieurs avantages :

  • Le fait de restaurer moins de données réduit le temps nécessaire pour les copier et les récupérer.

  • Dans SQL Server, la restauration des pages ou des fichiers peut permettre à d’autres données de la base de données de rester en ligne pendant l’opération de restauration.

Récupération et journal des transactions

Pour la plupart des scénarios de restauration, il est nécessaire d’appliquer une sauvegarde du journal des transactions et de permettre au moteur de base de données SQL Server d’exécuter le processus de récupération pour que la base de données soit mise en ligne. La récupération est le processus que SQL Server utilise pour chaque base de données pour démarrer dans un état cohérent (ou propre) en termes de transaction.

En cas de basculement ou d’un autre arrêt brutal, il se peut que les bases de données soient laissées dans un état où certaines modifications n’ont jamais été écrites à partir du cache tampon dans les fichiers de données, et des modifications provenant de transactions incomplètes peuvent se trouver dans les fichiers de données. Lorsqu’une instance de SQL Server est démarrée, elle exécute une récupération de chaque base de données, ce qui comporte trois phases, en fonction du dernier point de contrôle de base de données :

  • La phase 1 est la phase d’analyse qui analyse le journal des transactions pour déterminer quel est le dernier point de contrôle, et crée les tables DPT (Dirty Page Table) et ATT (Active Transaction Table). La table DPT contient les enregistrements des pages qui étaient incorrectes au moment de l’arrêt de la base de données. La table ATT contient les enregistrements de transactions qui étaient actives au moment où la base de données n’a pas été arrêtée correctement.

  • La Phase 2 est la Phase de restauration qui restaure par progression toutes les modifications enregistrées dans le journal qui n’ont peut-être pas été écrites dans les fichiers de données au moment où la base de données a été arrêtée. Le numéro minimal de séquence du journal (minLSN) requis pour une récupération réussie de l’ensemble de la base de données se trouve dans la DPT et marque le début des opérations de réexécution nécessaires sur toutes les pages modifiées. À ce stade, e moteur de base de données SQL Server écrit sur le disque toutes les pages incorrectes appartenant aux transactions validées.

  • La phase 3 est la phase d’annulation, qui annule les transactions incomplètes trouvées dans l’ATT afin de garantir la préservation de l’intégrité de la base de données. Après la restauration, la base de données passe en ligne, et aucune autre sauvegarde du journal des transactions ne peut être appliquée à la base de données.

Les informations sur la progression de chaque phase de la récupération de la base de données sont consignées dans le journal des erreurs SQL Server. La progression de la récupération de la base de données peut également être suivie via Événements étendus. Pour plus d’informations, consultez le billet de blog New extended events for database recovery progress (Nouveaux événements étendus pour la progression de la récupération de la base de données).

Note

Dans le cas d’un scénario de restauration partielle, si un groupe de fichiers est en lecture seule depuis avant la création de la sauvegarde du fichier, l’application des sauvegardes du journal au groupe de fichiers n’est pas nécessaire et est ignorée lors de la restauration du fichier.

Note

Pour optimiser la disponibilité des bases de données dans un environnement d’entreprise après le démarrage du service SQL Server, par exemple après un basculement d’une instance de cluster de basculement Always On ou redémarrage sur place, SQL Server Êdition Entreprise peut mettre en ligne une base de données après la phase de restauration, tandis que la phase d’annulation est toujours en cours d’exécution. Cela s’appelle la récupération rapide. Toutefois, la récupération rapide n’est pas disponible lorsque la base de données passe à un état en ligne, mais que le service SQL Server n’a pas été redémarré. Par exemple, l’exécution de ALTER DATABASE AdventureWorks SET ONLINE; n’autorise pas la base de données à être en lecture et en écriture tant que les trois phases de récupération n’ont pas été terminées.

Modes de récupération et opérations de restauration prises en charge

Les opérations de restauration disponibles pour une base de données dépendent de son mode de récupération. Le tableau suivant présente le niveau de prise en charge des modes de récupération dans un scénario de restauration donné.

Opération de restauration Mode de restauration complète Mode de récupération en mode bloc Mode de récupération simple
Récupération de données Restauration complète (si le journal des transactions est disponible). Risque de perte de données. Les données postérieures à la dernière sauvegarde différentielle ou complète sont perdues.
Restauration dans le temps Toute heure couverte par les sauvegardes de fichiers journaux. Non autorisé si la sauvegarde de fichier journal contient des modifications journalisées en bloc. Non pris en charge.
Restauration de fichiers 1 Prise en charge complète. Sometimes. 2 Disponible uniquement pour les fichiers secondaires en lecture seule.
Restauration de pages 1 Prise en charge complète. Sometimes. 2 None.
Restauration fragmentaire (niveau groupe de fichiers) 1 Prise en charge complète. Sometimes. 2 Disponible uniquement pour les fichiers secondaires en lecture seule.

1 Disponible uniquement dans l’édition Enterprise de SQL Server.

2 Pour les conditions requises, consultez Restrictions de restauration en mode de récupération simple, plus loin dans cet article.

Important

Quel que soit le mode de récupération d’une base de données, une sauvegarde SQL Server ne peut pas être restaurée vers une version du moteur de base de données SQL Server antérieure à la version qui a créé la sauvegarde.

Scénarios de restauration en mode de récupération simple

Le mode de récupération simple impose les restrictions suivantes aux opérations de restauration :

Si ces restrictions ne correspondent pas à vos besoins de récupération, nous vous recommandons d'envisager le mode de restauration complète. Pour plus d’informations, consultez vue d’ensemble de la sauvegarde (SQL Server).

Important

Quel que soit le mode de récupération d’une base de données, une sauvegarde SQL Server ne peut pas être restaurée par une version de SQL Server antérieure à la version qui a créé la sauvegarde.

Restauration sous le mode de récupération en journalisation en bloc

Cette section traite des considérations relatives à la restauration propres au mode de récupération en journalisation minimale, lequel est destiné exclusivement à compléter le mode de récupération complet.

Note

Pour une présentation du modèle de récupération journalisée en bloc, consultez Le journal des transactions.

Généralement, le mode de récupération en mode journalisation en bloc est similaire au mode de récupération complet, et les informations décrites pour le mode de récupération complet s’appliquent également aux deux. Cependant, la récupération à un moment précis et la restauration en ligne sont affectées par le mode de récupération en journalisation en bloc.

Restrictions de la restauration à un instant donné

Si une sauvegarde du journal effectuée sous le mode de récupération avec journalisation en bloc contient des modifications journalisées en bloc, la restauration à un instant donné n’est pas possible. La tentative d’exécution d’une récupération dans le temps sur une sauvegarde de journal contenant des modifications en bloc entraîne l’échec de l’opération de restauration.

Restrictions relatives à la restauration en ligne

Une séquence de restauration en ligne fonctionne uniquement si les conditions suivantes sont satisfaites :

  • Toutes les sauvegardes de journaux nécessaires doivent avoir été effectuées avant le démarrage de la séquence de restauration.

  • Les modifications en bloc doivent avoir été sauvegardées avant de démarrer la séquence de restauration en ligne.

  • Si des changements en masse existent dans la base de données, tous les fichiers doivent être en ligne ou inactifs (autrement dit, ne faisant plus partie de la base de données).

Si ces conditions ne sont pas satisfaites, la séquence de restauration en ligne échoue.

Note

Il est recommandé de basculer en mode de restauration complète avant de démarrer la restauration en ligne. Pour plus d’informations, consultez modèles de récupération (SQL Server).

Pour plus d’informations sur l’exécution d’une restauration en ligne, consultez Restauration en ligne (SQL Server).

Assistant de récupération de base de données (SQL Server Management Studio)

L'Assistant Récupération de base de données permet de créer des plans de restauration qui implémentent des séquences de restauration correctes et optimales. De nombreux problèmes connus, liés à la restauration de la base de données, et améliorations demandées par les clients ont été pris en considération. Les principales améliorations introduites par l’Assistant Récupération de base de données sont les suivantes :

  • Algorithme de plan de restauration : l’algorithme utilisé pour créer des plans de restauration a été amélioré considérablement, en particulier pour les scénarios de restauration complexes. Nombre de cas limites, notamment la réplication de scénarios dans les restaurations ponctuelles, sont gérés plus efficacement que dans les versions antérieures de SQL Server.

  • Restaurations à un point dans le temps : l’Assistant de récupération de base de données simplifie considérablement la restauration d’une base de données à un point précis dans le temps. Une chronologie visuelle de sauvegarde améliore considérablement la prise en charge des restaurations dans le temps. La chronologie visuelle vous permet d'identifier un point possible comme point de récupération cible pour restaurer une base de données. La chronologie permet de parcourir un chemin de récupération à embranchements (un chemin qui traverse les embranchements de récupération). Un plan spécifique de restauration dans le temps inclut automatiquement les sauvegardes pertinentes pour la restauration à un point cible (date et heure). Pour plus d’informations, consultez Restaurer une base de données SQL Server jusqu’à une limite dans le temps (mode de récupération complète).

Pour plus d’informations sur l’Assistant Récupération de base de données, consultez les blogs de gestion SQL Server suivants :

Récupération de base de données accélérée

récupération de base de données accélérée (ADR) est disponible à partir de SQL Server 2019 (15.x). ADR est également disponible dans Azure SQL Database, Azure SQL Managed Instance, Azure Synapse Analytics (pool SQL dédié uniquement) et la base de données SQL dans Microsoft Fabric. La récupération de base de données accélérée améliore considérablement la disponibilité des bases de données, notamment en présence de transactions durables, en redéfinissant le processus de récupération du moteur de base de données SQL Server. Une base de données avec ADR activée achève le processus de récupération beaucoup plus rapidement après un basculement ou un autre arrêt inattendu. Lorsque l’ADR est activé, la restauration des transactions longues annulées se termine instantanément.

Vous pouvez activer ADR par base de données dans SQL Server 2019 (15.x) et versions ultérieures à l’aide de la syntaxe suivante :

ALTER DATABASE [<db_name>] SET ACCELERATED_DATABASE_RECOVERY = ON;

Note

ADR est toujours activé dans Azure SQL Database, Azure SQL Managed Instance, Azure Synapse Analytics (pool SQL dédié uniquement) et la base de données SQL dans Microsoft Fabric.

Contenu connexe

  • Last updated on