Partager via

Instructions RESTORE (Transact-SQL)

  • Article

Restaure les sauvegardes de bases de données SQL réalisées à l’aide de la commande BACKUP.

Sélectionner un produit

Sur la ligne suivante, sélectionnez le nom du produit qui vous intéresse afin d’afficher uniquement les informations qui le concernent.

Pour plus d’informations sur les conventions de la syntaxe, consultez Conventions de la syntaxe Transact-SQL.

* SQL Server *  

SQL Managed Instance

Analytics Platform
System (PDW)

 

SQL Server

Cette commande vous permet d'effectuer les scénarios de restauration suivants :

  • Restaurer une base de données complète à partir d'une sauvegarde de base de données complète (restauration complète)
  • Restaurer une partie d'une base de données (restauration partielle)
  • Restaurer des fichiers ou des groupes de fichiers spécifiques dans une base de données (restauration de fichiers)
  • Restaurer des pages spécifiques dans une base de données (restauration de pages)
  • Restaurer un journal des transactions dans une base de données (restauration de journal des transactions)
  • Rétablir une base de données au point d'instantané de base de données.

Autres ressources

Syntaxe

--To Restore an Entire Database from a Full database backup (a Complete Restore):
RESTORE DATABASE { database_name | @database_name_var }
 [ FROM <backup_device> [ ,...n ] ]
 [ WITH
   {
    [ RECOVERY | NORECOVERY | STANDBY =
        {standby_file_name | @standby_file_name_var }
       ]
   | ,  <general_WITH_options> [ ,...n ]
   | , <replication_WITH_option>
   | , <change_data_capture_WITH_option>
   | , <FILESTREAM_WITH_option>
   | , <service_broker_WITH options>
   | , <point_in_time_WITH_options-RESTORE_DATABASE>
   } [ ,...n ]
 ]
[;]

--To perform the first step of the initial restore sequence of a piecemeal restore:
RESTORE DATABASE { database_name | @database_name_var }
   <files_or_filegroups> [ ,...n ]
 [ FROM <backup_device> [ ,...n ] ]
   WITH
      PARTIAL, NORECOVERY
      [  , <general_WITH_options> [ ,...n ]
       | , <point_in_time_WITH_options-RESTORE_DATABASE>
      ] [ ,...n ]
[;]

--To Restore Specific Files or Filegroups:
RESTORE DATABASE { database_name | @database_name_var }
   <file_or_filegroup> [ ,...n ]
 [ FROM <backup_device> [ ,...n ] ]
   WITH
   {
      [ RECOVERY | NORECOVERY ]
      [ , <general_WITH_options> [ ,...n ] ]
   } [ ,...n ]
[;]

--To Restore Specific Pages:
RESTORE DATABASE { database_name | @database_name_var }
   PAGE = 'file:page [ ,...n ]'
 [ , <file_or_filegroups> ] [ ,...n ]
 [ FROM <backup_device> [ ,...n ] ]
   WITH
       NORECOVERY
      [ , <general_WITH_options> [ ,...n ] ]
[;]

--To Restore a Transaction Log:
RESTORE LOG { database_name | @database_name_var }
 [ <file_or_filegroup_or_pages> [ ,...n ] ]
 [ FROM <backup_device> [ ,...n ] ]
 [ WITH
   {
     [ RECOVERY | NORECOVERY | STANDBY =
        {standby_file_name | @standby_file_name_var }
       ]
    | , <general_WITH_options> [ ,...n ]
    | , <replication_WITH_option>
    | , <point_in_time_WITH_options-RESTORE_LOG>
   } [ ,...n ]
 ]
[;]

--To Revert a Database to a Database Snapshot:
RESTORE DATABASE { database_name | @database_name_var }
FROM DATABASE_SNAPSHOT = database_snapshot_name

<backup_device>::=
{
   { logical_backup_device_name |
      @logical_backup_device_name_var }
 | { DISK
     | TAPE
     | URL
   } = { 'physical_backup_device_name' |
      @physical_backup_device_name_var }
}

<files_or_filegroups>::=
{
   FILE = { logical_file_name_in_backup | @logical_file_name_in_backup_var }
 | FILEGROUP = { logical_filegroup_name | @logical_filegroup_name_var }
 | READ_WRITE_FILEGROUPS
}

<general_WITH_options> [ ,...n ]::=
--Restore Operation Options
   MOVE 'logical_file_name_in_backup' TO 'operating_system_file_name'
          [ ,...n ]
 | REPLACE
 | RESTART
 | RESTRICTED_USER | CREDENTIAL

--Backup Set Options
 | FILE = { backup_set_file_number | @backup_set_file_number }
 | PASSWORD = { password | @password_variable }
 | [ METADATA_ONLY | SNAPSHOT ] [ DBNAME = { database_name | @database_name_variable } ]

--Media Set Options
 | MEDIANAME = { media_name | @media_name_variable }
 | MEDIAPASSWORD = { mediapassword | @mediapassword_variable }
 | BLOCKSIZE = { blocksize | @blocksize_variable }

--Data Transfer Options
 | BUFFERCOUNT = { buffercount | @buffercount_variable }
 | MAXTRANSFERSIZE = { maxtransfersize | @maxtransfersize_variable }

--Error Management Options
 | { CHECKSUM | NO_CHECKSUM }
 | { STOP_ON_ERROR | CONTINUE_AFTER_ERROR }

--Monitoring Options
 | STATS [ = percentage ]

--Tape Options.
 | { REWIND | NOREWIND }
 | { UNLOAD | NOUNLOAD }

<replication_WITH_option>::=
 | KEEP_REPLICATION

<change_data_capture_WITH_option>::=
 | KEEP_CDC

<FILESTREAM_WITH_option>::=
 | FILESTREAM ( DIRECTORY_NAME = directory_name )

<service_broker_WITH_options>::=
 | ENABLE_BROKER
 | ERROR_BROKER_CONVERSATIONS
 | NEW_BROKER

<point_in_time_WITH_options-RESTORE_DATABASE>::=
 | {
   STOPAT = { 'datetime'| @datetime_var }
 | STOPATMARK = 'lsn:lsn_number'
                 [ AFTER 'datetime']
 | STOPBEFOREMARK = 'lsn:lsn_number'
                 [ AFTER 'datetime']
   }

<point_in_time_WITH_options-RESTORE_LOG>::=
 | {
   STOPAT = { 'datetime'| @datetime_var }
 | STOPATMARK = { 'mark_name' | 'lsn:lsn_number' }
                 [ AFTER 'datetime']
 | STOPBEFOREMARK = { 'mark_name' | 'lsn:lsn_number' }
                 [ AFTER 'datetime']
   }

Arguments

Pour une description des arguments, consultez l’article Instructions RESTORE – Arguments .

À propos des scénarios de restauration

SQL Server prend en charge un large éventail de scénarios de restauration :

Si la restauration en ligne est prise en charge et si la base de données est en ligne, les restaurations de fichiers et de pages s'effectuent automatiquement en ligne, ainsi que les restaurations du groupe de fichiers secondaire une fois la phase initiale de restauration fragmentaire effectuée.

Notes

Les restaurations en ligne peuvent impliquer des transactions différées.

Pour plus d’informations, consultez l’article Restauration en ligne.

Considérations supplémentaires à propos des options RESTORE

Mots clés RESTORE supprimés

Les mots clés suivants ont été supprimés dans SQL Server 2008 (10.0.x) :

Mot clé supprimé Remplacé par... Exemple de mot clé de remplacement
LOAD RESTORE RESTORE DATABASE
TRANSACTION LOG RESTORE LOG
DBO_ONLY RESTRICTED_USER RESTORE DATABASE ... WITH RESTRICTED_USER

RESTORE LOG

RESTORE LOG peut contenir une liste de fichiers pour permettre la création des fichiers lors de la restauration par progression. Elle est utilisée lorsque la sauvegarde du journal contient des enregistrements qui ont été écrits lorsqu'un fichier a été ajouté à la base de données.

Notes

Pour une base de données en mode de récupération complète ou en mode de récupération utilisant les journaux de transactions, vous devez dans la plupart des cas effectuer une sauvegarde de la fin du journal, avant la restauration de la base de données. Restaurer une base de données sans effectuer une sauvegarde de la fin du journal au préalable entraîne une erreur, sauf si l'instruction RESTORE DATABASE contient la clause WITH REPLACE ou WITH STOPAT, qui doit spécifier une heure ou une transaction qui s'est produite après la fin de la sauvegarde des données. Pour plus d’informations sur les sauvegardes de la fin du journal, consultez l’article Sauvegardes de la fin du journal.

Comparaison entre RECOVERY et NORECOVERY

La restauration est contrôlée par l'instruction RESTORE et les options [ RECOVERY | NORECOVERY ] :

  • NORECOVERY indique que la restauration ne s'effectue pas. Cela permet la poursuite de la restauration par progression avec l'instruction suivante de la séquence.

    Dans ce cas, la séquence de restauration restaure d'autres sauvegardes, puis les restaure par progression.

  • RECOVERY (valeur par défaut) indique que la restauration doit être effectuée après la restauration par progression de la sauvegarde actuelle. Aucune autre sauvegarde ne peut être restaurée. Sélectionnez cette option une fois que vous avez restauré toutes les sauvegardes nécessaires.

    Pour récupérer la base de données, le jeu de données faisant l’objet de la restauration (jeu de restauration par progression) doit être entièrement cohérent par rapport à la base de données. Si la restauration par progression du jeu de restauration par progression n'est pas allée assez loin pour être cohérente par rapport à la base de données et si l'option RECOVERY est spécifiée, le Moteur de base de données génère une erreur. Pour plus d’informations sur le processus de récupération, consultez Vue d’ensemble de la restauration et de la récupération (SQL Server).

Prise en charge de la compatibilité

Les sauvegardes de bases de données master, model et msdb créées avec une version plus ancienne de SQL Server ne peuvent pas être restaurées par SQL Server.

Notes

Aucune sauvegarde SQL Server ne peut être restaurée dans une version de SQL Server antérieure à celle sur laquelle la sauvegarde a été créée.

Chaque version de SQL Server utilise un chemin d'accès par défaut différent de celui des versions antérieures. Par conséquent, pour restaurer une base de données créée à l'emplacement par défaut des sauvegardes de version antérieure, vous devez utiliser l'option MOVE. Pour plus d’informations sur le nouveau chemin par défaut, consultez Emplacements des fichiers pour les instances par défaut et les instances nommées de SQL Server.

Après avoir restauré une base de données de version antérieure dans SQL Server, la base de données est automatiquement mise à niveau. En général, la base de données est immédiatement disponible. Toutefois, si une base de données SQL Server 2005 (9.x) comprend des index de recherche en texte intégral, le processus de mise à niveau les importe, les réinitialise ou les reconstruit, selon la valeur de la propriété de serveur upgrade_option. Si l’option de mise à niveau a la valeur Importer (upgrade_option = 2) ou Reconstruire (upgrade_option = 0), les index de recherche en texte intégral ne seront pas disponibles pendant la mise à niveau. Selon le volume de données indexé, l'importation peut prendre plusieurs heures et la reconstruction jusqu'à dix fois plus longtemps. Notez également que lorsque l'option de mise à niveau est Importer, les index de recherche en texte intégral associés sont reconstruits si aucun catalogue de texte intégral n'est disponible. Pour modifier le paramètre de la propriété de serveur upgrade_option , utilisez sp_fulltext_service.

Lorsqu'une base de données est attachée ou restaurée pour la première fois à une nouvelle instance de SQL Server, une copie de la clé principale de la base de données (chiffrée par la clé principale du service) n'est pas encore stockée sur le serveur. Vous devez utiliser l’instruction OPEN MASTER KEY pour déchiffrer la clé principale de la base de données. Une fois la clé principale de la base de données déchiffrée, vous avez la possibilité d’activer le déchiffrement automatique dans le futur en exécutant l’instruction ALTER MASTER KEY REGENERATE pour fournir au serveur une copie de la clé principale de la base de données chiffrée avec la clé principale du service. Lorsqu'une base de données a été mise à niveau à partir d'une version antérieure, la clé DMK doit être régénérée de façon à utiliser le nouvel algorithme AES. Pour plus d’informations sur la régénération de la clé DMK, consultez l’article ALTER MASTER KEY. La durée nécessaire pour régénérer la clé DMK à mettre à niveau vers AES dépend du nombre d'objets protégés par la clé DMK. La régénération de la clé DMK à mettre à niveau vers AES est nécessaire une seule fois et n'a aucune incidence sur les régénérations ultérieures effectuées dans le cadre d'une stratégie de rotation de clés.

Notes

Lors d'une restauration hors ligne, si la base de données spécifiée est en cours d'utilisation, RESTORE force la déconnexion des utilisateurs après un court délai. Pour la restauration en ligne d'un groupe de fichiers non primaire, la base de données peut rester active, sauf si le groupe de fichiers restaurés est hors ligne. Toutes les données que la base contient sont remplacées par les données restaurées.

Les opérations de restauration inter-plateformes, impliquant éventuellement des types de processeurs différents, peuvent être réalisées tant que le classement de la base de données est pris en charge par le système d'exploitation.

La commande RESTORE peut être redémarrée après une erreur. En outre, vous pouvez contraindre la commande RESTORE à poursuivre son traitement en dépit des erreurs. Elle restaure ainsi le plus de données possible (voir l'option CONTINUE_AFTER_ERROR).

La commande RESTORE n'est pas autorisée dans une transaction explicite ou implicite.

La restauration d’une base de données master endommagée s’effectue selon une procédure spéciale. Pour plus d’informations, consultez l’article Sauvegarder et restaurer des bases de données système.

La restauration d’une base de données efface le cache de plan pour la base de données en cours de restauration. Cette opération entraîne la recompilation de tous les plans d'exécution ultérieurs et peut entraîner une baisse temporaire et brutale des performances des requêtes.

Pour restaurer une base de données de disponibilité, restaurez d'abord la base de données en tant qu'instance SQL Server, puis ajoutez la base de données au groupe de disponibilité.

Accélération et déchargement intégrés pour la compression et la décompression de sauvegarde

SQL Server 2022 (16.x) introduit ALGORITHM, qui identifie un algorithme de compression pour l’opération. Pour plus d’informations, consultez Backup COMPRESSION.

Pour plus d’informations, consultez Opérations de restauration.

Restaurer à partir de l'URL

L’URL est le format utilisé pour spécifier l’emplacement et le nom de fichier du Stockage Blob Microsoft Azure ou du stockage d’objets compatible S3. Bien que le Stockage Blob Azure constitue un service, son implémentation est similaire à celle d’un disque ou d’une bande afin d’offrir une expérience de restauration cohérente et fluide pour tous les appareils.

Interopérabilité

Paramètres et restauration des bases de données

Lors d'une restauration, les valeurs de la plupart des options de base de données pouvant être définies avec ALTER DATABASE et en vigueur à la fin de la sauvegarde sont rétablies.

Cependant, l'utilisation de WITH RESTRICTED_USER annule ce comportement pour le paramètre de l'option d'accès utilisateur. Ce paramètre est toujours défini suivant une instruction RESTORE qui inclut l'option WITH RESTRICTED_USER.

Restauration d’une base de données chiffrée

Pour restaurer une base de données chiffrée, vous devez avoir accès au certificat ou à la clé asymétrique qui a servi à chiffrer la base de données. Sans le certificat et la clé asymétrique, la base de données ne peut pas être restaurée. En conséquence, le certificat utilisé pour chiffrer la clé de chiffrement de base de données doit être conservé tant que la sauvegarde est utile. Pour plus d'informations, consultez SQL Server Certificates and Asymmetric Keys.

Restauration d’une base de données sur laquelle le stockage vardecimal est activé

Les sauvegardes et les restaurations fonctionnent correctement avec le format de stockage vardecimal. Pour plus d’informations sur le format de stockage vardecimal, consultez l’article sp_db_vardecimal_storage_format.

Restauration de données de texte intégral

Les données de texte intégral sont restaurées avec d'autres données de base de données lors d'une restauration complète. La syntaxe régulière RESTORE DATABASE database_name FROM backup_device permet de restaurer les fichiers de texte intégral comme des éléments faisant partie intégrante de la restauration de fichiers de base de données.

L'instruction RESTORE permet également d'effectuer des restaurations dans d'autres emplacements, des restaurations différentielles, des restaurations de fichiers et de groupes de fichiers, ainsi que des restaurations de fichiers et groupes de fichiers différentielles de données de texte intégral. En outre, cette instruction permet de restaurer des fichiers de texte intégral uniquement, ainsi que des données de base de données.

Notes

Les catalogues de texte intégral importés à partir de SQL Server 2005 (9.x) sont toujours traités en tant que fichiers de base de données. Pour ceux-ci, la procédure SQL Server 2005 (9.x) de sauvegarde des catalogues de texte intégral reste applicable, mais la suspension et la reprise en cours de sauvegarde ne sont plus nécessaires. Pour plus d’informations, consultez Sauvegarde et restauration de catalogues de texte intégral.

Restaurer sur SQL Server 2022 et la fonctionnalité de suppression automatique

Pour restaurer une base de données sur SQL Server 2022 (16.x) à partir d’une version précédente, il est recommandé d’exécuter sp_updatestats sur la base de données, en définissant les métadonnées appropriées pour la fonctionnalité de suppression automatique des statistiques. Pour plus d’informations, consultez Option de suppression automatique des statistiques.

Clusters Big Data SQL Server

Certaines opérations, notamment la configuration des paramètres de serveur (niveau d’instance) ou l’ajout manuel d’une base de données à un groupe de disponibilité, nécessitent une connexion à l’instance SQL Server. Les opérations comme sp_configure, RESTORE DATABASE ou n’importe quelle commande DDL dans une base de données appartenant à un groupe de disponibilité nécessitent une connexion à l’instance SQL Server. Par défaut, un cluster Big Data ne comporte pas de point de terminaison permettant une connexion à l’instance. Vous devez exposer ce point de terminaison manuellement.

Pour obtenir des instructions, consultez Se connecter aux bases de données sur le réplica principal.

Métadonnées

SQL Server intègre des tables d'historique de sauvegarde et de restauration qui assurent le suivi des activités de sauvegarde et de restauration pour chaque instance de serveur. Lorsqu'une restauration est effectuée, les tables d'historique de sauvegarde sont également modifiées. Pour plus d’informations sur ces tables, consultez l’article Historique de sauvegarde et informations d’en-tête.

Impact de l’option REPLACE

L'option REPLACE ne doit être utilisée que rarement et après un examen attentif. Généralement, la restauration empêche le remplacement accidentel d'une base de données par une autre. Si la base de données nommée dans l'instruction RESTORE existe déjà sur le serveur actif et que le GUID de famille de la base de données spécifié ne correspond pas à celui qui est enregistré dans le jeu de sauvegarde, la base de données n'est pas restaurée. Cette mesure de sécurité est très importante,

L'option REPLACE annule d'importants contrôles de sécurité normalement effectués lors d'une restauration. Ces contrôles ignorés sont les suivants :

  • Restauration par remplacement d'une base de données existante par une sauvegarde d'une autre base de données.

    Avec l'option REPLACE, la restauration vous permet de remplacer une base de données existante par la base de données figurant dans le jeu de sauvegarde, même si le nom de base de données spécifié diffère de celui enregistré dans le jeu en question. Cela peut entraîner un remplacement accidentel d'une base de données par une autre.

  • Restauration par remplacement d’une base de données à l’aide du mode de récupération complète ou du mode de récupération utilisant les journaux de transactions quand aucune sauvegarde de la fin du journal n’a été réalisée et que l’option STOPAT n’est pas employée.

    Avec l'option REPLACE, vous pouvez perdre des transactions déjà validées du fait que le dernier journal écrit n'a pas été sauvegardé.

  • Remplacement des fichiers existants

    Par exemple, une erreur peut entraîner le remplacement des fichiers existants d'un type incorrect (par exemple, fichiers .xls) ou de fichiers actuellement utilisés par une autre base de données qui n'est pas en ligne. Une perte de données arbitraire peut avoir lieu si des fichiers existants sont remplacés, même si la base de données restaurée est complète.

Recommencer une restauration

Il n'est pas possible d'annuler les effets d'une restauration. Cependant, vous pouvez annuler les effets de la copie et de la restauration par progression des données en recommençant fichier par fichier. Pour recommencer, restaurez le fichier approprié et réeffectuez la restauration par progression. Par exemple, si vous avez accidentellement restauré trop de sauvegardes du journal et dépassé le point d'arrêt voulu, redémarrez la séquence.

Une séquence de restauration peut être annulée et redémarrée en restaurant l'ensemble du contenu des fichiers concernés.

Rétablir une base de données à un instantané de base de données

Une opération de rétablissement de base de données (spécifiée avec l’option DATABASE_SNAPSHOT) ramène une base de données source complète à un moment donné dans le temps, en rétablissant l’instantané de base de données à cet instant-là, c’est-à-dire en remplaçant la base de données source par les données correspondant à une date et heure précises dans l’instantané de base de données spécifié. Seul l'instantané vers lequel vous effectuez le rétablissement peut exister. Cette opération reconstruit ensuite le journal (par conséquent, vous ne pouvez pas effectuer une restauration par progression d'une base de données rétablie au point d'erreur de l'utilisateur).

La perte de données est limitée aux mises à jour de la base de données depuis la création de l'instantané. Les métadonnées d'une base de données rétablie sont identiques aux métadonnées au moment de la création de l'instantané. Toutefois, le retour à un instantané supprime tous les catalogues de texte intégral.

Le rétablissement à partir d'un instantané de base de données n'est pas destiné à la récupération des supports. Contrairement à un jeu de sauvegarde classique, l'instantané de base de données est une copie incomplète des fichiers de la base de données. Si la base de données ou l'instantané de base de données est endommagé, le rétablissement à partir d'un instantané sera probablement impossible. En outre, même lorsque le rétablissement est possible, il est peu probable qu'il permette de corriger le problème en cas de dommages.

Restrictions liées au rétablissement

Le rétablissement n'est pas pris en charge dans les conditions suivantes :

  • La base de données source contient des groupes de fichiers en lecture seule ou compressés.
  • Des fichiers sont hors connexion alors qu'ils étaient en ligne lors de la création de l'instantané.
  • Il existe plus d'un instantané de la base de données.

Pour plus d’informations, consultez Rétablir une base de données dans l’état d’un instantané de base de données.

Sécurité

Une opération de sauvegarde peut éventuellement spécifier des mots de passe pour un support de sauvegarde, un jeu de sauvegarde ou les deux. Lorsqu'un mot de passe a été défini sur un support de sauvegarde ou un jeu de sauvegarde, vous devez entrer le ou les mots de passe corrects dans l'instruction RESTORE. Ces mots de passe empêchent les opérations non autorisées de restauration et d’ajout de jeux de sauvegarde au support à l’aide d’outils SQL Server. Cependant, les supports protégés par un mot de passe peuvent être remplacés par l'option FORMAT de l'instruction BACKUP.

Important

Le niveau de protection de ce mot de passe est faible. Son but est d'éviter que des utilisateurs autorisés ou non autorisés effectuent une restauration incorrecte à l'aide des outils SQL Server. En aucun cas, elle n'empêche la lecture des données de la sauvegarde par d'autres moyens ou le remplacement du mot de passe. Cette fonctionnalité sera supprimée dans une version future de SQL Server. Évitez d'utiliser cette fonctionnalité dans de nouveaux travaux de développement, et prévoyez de modifier les applications qui utilisent actuellement cette fonctionnalité. La méthode conseillée en matière de protection des sauvegardes consiste à stocker les bandes de sauvegarde dans un emplacement sûr ou à sauvegarder les données sur des fichiers disque protégés par une liste de contrôle d'accès (ACL) appropriée. La liste de contrôle d'accès doit être définie à la racine du répertoire dans lequel les sauvegardes sont effectuées.

Autorisations

Si la base de données restaurée n'existe pas, l'utilisateur doit posséder les autorisations CREATE DATABASE afin de pouvoir exécuter RESTORE. Si la base de données existe, les autorisations RESTORE reviennent par défaut aux membres des rôles serveur fixe sysadmin et dbcreator et au propriétaire (dbo) de la base de données (pour l’option FROM DATABASE_SNAPSHOT, la base de données existe toujours).

Les autorisations RESTORE sont attribuées aux rôles dont les informations d'appartenance sont toujours immédiatement accessibles à partir du serveur. Étant donné que l’appartenance au rôle de base de données fixe ne peut être contrôlée que quand la base de données est accessible et non endommagée, ce qui n’est pas toujours le cas lorsque RESTORE est exécuté, les membres du rôle de base de données fixe db_owner ne détiennent pas d’autorisations RESTORE.

Exemples

Tous les exemples partent du principe qu'une sauvegarde complète de la base de données a été effectuée.

Parmi les exemples d'instruction RESTORE, citons :

Notes

Pour obtenir d’autres exemples, consultez les rubriques de procédures de restauration répertoriées dans l’article Vue d’ensemble de la restauration et de la récupération.

R. Restaurer une base de données complète

L'exemple suivant restaure une sauvegarde de base de données complète à partir de l'unité de sauvegarde logique AdventureWorksBackups. Pour obtenir un exemple de création de cette unité, consultez Unités de sauvegarde.

RESTORE DATABASE AdventureWorks2022
  FROM AdventureWorks2022Backups;

Notes

Pour une base de données en mode de récupération complète ou utilisant les journaux de transactions, SQL Server nécessite dans la plupart des cas une sauvegarde de la fin du journal, avant la restauration de la base de données. Pour plus d’informations, consultez l’article Sauvegardes de la fin du journal.

[Début des exemples]

B. Restaurer des sauvegardes complètes et différentielles d’une base de données

L'exemple suivant restaure une sauvegarde de base de données complète, puis une sauvegarde différentielle, à partir de l'unité de sauvegarde Z:\SQLServerBackups\AdventureWorks2022.bak qui contient les deux sauvegardes. La sauvegarde de base de données complète à restaurer correspond au sixième jeu de sauvegarde se trouvant sur l'unité (FILE = 6), tandis que la sauvegarde de base de données différentielle correspond au neuvième jeu de sauvegarde se trouvant sur l'unité (FILE = 9). Une fois la sauvegarde différentielle récupérée, la récupération de la base de données est terminée.

RESTORE DATABASE AdventureWorks2022
    FROM DISK = 'Z:\SQLServerBackups\AdventureWorks2022.bak'
    WITH FILE = 6,
      NORECOVERY;
RESTORE DATABASE AdventureWorks2022
    FROM DISK = 'Z:\SQLServerBackups\AdventureWorks2022.bak'
    WITH FILE = 9,
      RECOVERY;

[Début des exemples]

C. Restaurer une base de données en utilisant la syntaxe RESTART

Dans l'exemple suivant, l'option RESTART est utilisée pour redémarrer une opération RESTORE interrompue par une coupure de courant sur le serveur.

-- This database RESTORE halted prematurely due to power failure.
RESTORE DATABASE AdventureWorks2022
    FROM AdventureWorksBackups;
-- Here is the RESTORE RESTART operation.
RESTORE DATABASE AdventureWorks2022
    FROM AdventureWorksBackups WITH RESTART;

[Début des exemples]

D. Restauration d'une base de données et déplacement des fichiers

L'exemple suivant restaure l'intégralité d'une base de données et de son journal des transactions, puis déplace la base de données restaurée vers le répertoire C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\Data.

RESTORE DATABASE AdventureWorks2022
    FROM AdventureWorksBackups
    WITH NORECOVERY,
      MOVE 'AdventureWorks2022_Data' TO
'C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\Data\NewAdvWorks.mdf',
      MOVE 'AdventureWorks2022_Log'
TO 'C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\Data\NewAdvWorks.ldf';
RESTORE LOG AdventureWorks2022
    FROM AdventureWorksBackups
    WITH RECOVERY;

[Début des exemples]

E. Copier une base de données en utilisant BACKUP et RESTORE

L'exemple suivant utilise à la fois les instructions BACKUP et RESTORE pour effectuer une copie de la base de données AdventureWorks2022. L'instruction MOVE entraîne la restauration des données et du fichier journal aux emplacements spécifiés. L'instruction RESTORE FILELISTONLY permet de déterminer le nombre et le nom des fichiers de la base de données en cours de restauration. La nouvelle copie de la base de données se nomme TestDB. Pour plus d’informations, consultez l’article RESTORE FILELISTONLY.

BACKUP DATABASE AdventureWorks2022
    TO AdventureWorksBackups ;

RESTORE FILELISTONLY
    FROM AdventureWorksBackups ;

RESTORE DATABASE TestDB
    FROM AdventureWorksBackups
    WITH MOVE 'AdventureWorks2022_Data' TO 'C:\MySQLServer\testdb.mdf',
    MOVE 'AdventureWorks2022_Log' TO 'C:\MySQLServer\testdb.ldf';
GO

[Début des exemples]

F. Restaurer à un point dans le temps en utilisant STOPAT

L'exemple suivant restaure une base de données dans l'état où elle se trouvait le 12:00 AM à April 15, 2020 et décrit une opération de restauration impliquant plusieurs sauvegardes de fichiers journaux. Sur l'unité de sauvegarde AdventureWorksBackups, la sauvegarde de base de données complète à restaurer correspond au troisième jeu de sauvegarde (FILE = 3), la première sauvegarde de fichier journal correspond au quatrième jeu de sauvegarde (FILE = 4) et la seconde sauvegarde de fichier journal correspond au cinquième jeu de sauvegarde (FILE = 5).

RESTORE DATABASE AdventureWorks2022
    FROM AdventureWorksBackups
    WITH FILE = 3, NORECOVERY;

RESTORE LOG AdventureWorks2022
    FROM AdventureWorksBackups
    WITH FILE = 4, NORECOVERY, STOPAT = 'Apr 15, 2020 12:00 AM';

RESTORE LOG AdventureWorks2022
    FROM AdventureWorksBackups
    WITH FILE = 5, NORECOVERY, STOPAT = 'Apr 15, 2020 12:00 AM';
RESTORE DATABASE AdventureWorks2022 WITH RECOVERY;

[Début des exemples]

G. Restaurer le journal des transactions jusqu’à une marque

L'exemple suivant restaure le journal des transactions jusqu'à la marque dans la transaction marquée nommée ListPriceUpdate.

USE AdventureWorks2022;
GO
BEGIN TRANSACTION ListPriceUpdate
    WITH MARK 'UPDATE Product list prices';
GO

UPDATE Production.Product
    SET ListPrice = ListPrice * 1.10
    WHERE ProductNumber LIKE 'BK-%';
GO

COMMIT TRANSACTION ListPriceUpdate;
GO

-- Time passes. Regular database
-- and log backups are taken.
-- An error occurs in the database.
USE master;
GO

RESTORE DATABASE AdventureWorks2022
FROM AdventureWorksBackups
WITH FILE = 3, NORECOVERY;
GO

RESTORE LOG AdventureWorks2022
  FROM AdventureWorksBackups
    WITH FILE = 4,
    RECOVERY,
    STOPATMARK = 'UPDATE Product list prices';

[Début des exemples]

H. Restaurer en utilisant la syntaxe TAPE

L'exemple suivant restaure une sauvegarde de base de données complète à partir d'une unité de sauvegarde TAPE.

RESTORE DATABASE AdventureWorks2022
    FROM TAPE = '\\.\tape0';

[Début des exemples]

I. Restaurer en utilisant la syntaxe FILE et FILEGROUP

L'exemple suivant restaure une base de données nommée MyDatabase qui est composée de deux fichiers, d'un groupe de fichiers secondaire et d'un journal des transactions. La base de données utilise le mode de récupération complète.

La sauvegarde de la base de données est le neuvième jeu de sauvegarde dans le support de sauvegarde sur une unité de sauvegarde logique nommée MyDatabaseBackups. Trois sauvegardes de fichier journal, qui se trouvent dans les trois jeux de sauvegarde suivants (10, 11 et 12) sur l'unité MyDatabaseBackups sont ensuite restaurés à l'aide de WITH NORECOVERY. Une fois la dernière sauvegarde de fichier journal restaurée avec NORECOVERY, la base de données est récupérée.

Notes

La récupération est réalisée séparément afin d'éviter qu'elle n'ait lieu trop tôt, c'est-à-dire avant que la totalité des sauvegardes de fichier journal n'ait été restaurée. Pour plus d’informations sur le processus de récupération, consultez Vue d’ensemble de la restauration et de la récupération (SQL Server).

Dans l'instruction RESTORE DATABASE, il existe deux types d'options FILE. Les options FILE qui précèdent le nom de l'unité de sauvegarde spécifient les noms de fichiers logiques des fichiers de base de données à restaurer à partir du jeu de sauvegarde, par exemple FILE = 'MyDatabase_data_1'. Ce jeu de sauvegarde n'est pas la première sauvegarde de base de données dans le support de sauvegarde. Par conséquent, sa position dans le support de sauvegarde est indiquée via l'option FILE dans la clause WITH, en l'occurrence FILE = 9.

RESTORE DATABASE MyDatabase
    FILE = 'MyDatabase_data_1',
    FILE = 'MyDatabase_data_2',
    FILEGROUP = 'new_customers'
    FROM MyDatabaseBackups
    WITH
      FILE = 9,
      NORECOVERY;
GO
-- Restore the log backups
RESTORE LOG MyDatabase
    FROM MyDatabaseBackups
    WITH FILE = 10,
      NORECOVERY;
GO
RESTORE LOG MyDatabase
    FROM MyDatabaseBackups
    WITH FILE = 11,
      NORECOVERY;
GO
RESTORE LOG MyDatabase
    FROM MyDatabaseBackups
    WITH FILE = 12,
      NORECOVERY;
GO
--Recover the database
RESTORE DATABASE MyDatabase WITH RECOVERY;
GO

[Début des exemples]

J. Rétablissement à partir d’une capture instantanée de base de données

L'exemple suivant rétablit un instantané de base de données. Il part du principe qu'un seul instantané existe actuellement dans la base de données. Pour obtenir un exemple de la façon de créer cet instantané de base de données, consultez l’article Créer un instantané de base de données.

Notes

Le rétablissement d'un instantané supprime tous les catalogues de texte intégral.

USE master;
RESTORE DATABASE AdventureWorks2022 FROM DATABASE_SNAPSHOT = 'AdventureWorks_dbss1800';
GO

Pour plus d’informations, consultez Rétablir une base de données dans l’état d’un instantané de base de données.

[Début des exemples]

K. Restaurer à partir de Stockage Blob Microsoft Azure

Les trois exemples ci-dessous impliquent l’utilisation du service de stockage Microsoft Azure. Le nom du compte de stockage est mystorageaccount. Le conteneur des fichiers de données est appelé myfirstcontainer. Le conteneur des fichiers de sauvegarde est appelé mysecondcontainer. Une stratégie d’accès stockée a été créée avec des droits de lecture, écriture, suppression et liste pour chaque conteneur. Des informations d’identification SQL Server ont été créées en utilisant des signatures d’accès partagé associées aux stratégies d’accès stockées. Pour plus d’informations spécifiques sur la sauvegarde et la restauration SQL Server avec le Stockage Blob Microsoft Azure, consultez Sauvegarde et restauration SQL Server avec le Stockage Blob Microsoft Azure.

K1. Restaurer une sauvegarde complète de base de données à partir du service de stockage Microsoft Azure
Une sauvegarde complète de base de données située dans le conteneur mysecondcontainer de Sales sera restaurée dans myfirstcontainer. Sales n’existe actuellement pas sur le serveur.

RESTORE DATABASE Sales
  FROM URL = 'https://mystorageaccount.blob.core.windows.net/mysecondcontainer/Sales.bak'
  WITH MOVE 'Sales_Data1' to 'https://mystorageaccount.blob.core.windows.net/myfirstcontainer/Sales_Data1.mdf',
  MOVE 'Sales_log' to 'https://mystorageaccount.blob.core.windows.net/myfirstcontainer/Sales_log.ldf',
  STATS = 10;

K2. Restaurer une sauvegarde complète de base de données du service de stockage Microsoft Azure vers un stockage local Une sauvegarde complète de base de données située dans le conteneur mysecondcontainer de Sales sera restaurée dans le stockage local. Sales n’existe actuellement pas sur le serveur.

RESTORE DATABASE Sales
  FROM URL = 'https://mystorageaccount.blob.core.windows.net/mysecondcontainer/Sales.bak'
  WITH MOVE 'Sales_Data1' to 'H:\DATA\Sales_Data1.mdf',
  MOVE 'Sales_log' to 'O:\LOG\Sales_log.ldf',
  STATS = 10;

K3. Restaurer une sauvegarde complète de base de données du stockage local vers le service de stockage Microsoft Azure

RESTORE DATABASE Sales
  FROM DISK = 'E:\BAK\Sales.bak'
  WITH MOVE 'Sales_Data1' to 'https://mystorageaccount.blob.core.windows.net/myfirstcontainer/Sales_Data1.mdf',
  MOVE 'Sales_log' to 'https://mystorageaccount.blob.core.windows.net/myfirstcontainer/Sales_log.ldf',
  STATS = 10;

L. Restaurer à partir d’une sauvegarde d’instantané

Introduite dans SQL Server 2022 (16.x). Pour plus d’informations, consultez Créer une sauvegarde d’instantané Transact-SQL.

L1. Restaurer une sauvegarde complète

RESTORE DATABASE Sales
  FROM DISK = 'D:\MSSQL\Backup\SalesSnapshotFull.bkm'
  WITH METADATA_ONLY;

L2. Restaurer une sauvegarde et appliquer un journal des transactions

RESTORE DATABASE Sales
  FROM DISK = 'D:\MSSQL\Backup\SalesSnapshotFull.bkm'
  WITH METADATA_ONLY,
  NORECOVERY;

RESTORE LOG Sales
  FROM DISK = 'D:\MSSQL\Backup\SalesLog.trn'
  WITH RECOVERY;

L3. Restaurer à partir d’une sauvegarde d’instantané, et placer la base de données et les fichiers journaux à un nouvel emplacement

RESTORE DATABASE Sales
FROM DISK = 'D:\MSSQL\Backup\SalesSnapshotFull.bkm'
WITH METADATA_ONLY,
    MOVE Sales_Data TO 'D:\MSSQL\Sales.mdf',
    MOVE Sales_Log TO 'D:\MSSQL\Sales_log.ldf';

[Début des exemples]

Étapes suivantes

SQL Server

* SQL Managed Instance *

Analytics Platform
System (PDW)

 

Azure SQL Managed Instance

Cette commande vous permet de restaurer une base de données complète à partir d’une sauvegarde de base de données complète (restauration complète) depuis un compte Stockage Blob Azure.

Pour afficher d’autres commandes RESTORE prises en charge, consultez :

Important

Pour effectuer une restauration à partir de sauvegardes automatiques SQL Managed Instance, consultez Restauration de base de données SQL.

Syntaxe

--To Restore an Entire Database from a Full database backup (a Complete Restore):
RESTORE DATABASE { database_name | @database_name_var }
 FROM URL = { 'physical_device_name' | @physical_device_name_var } [ ,...n ]
[;]

Arguments

DATABASE

Spécifie la base de données cible.

FROM URL

Spécifie une ou plusieurs unités de sauvegarde placées sur les URL qui seront utilisées pour l’opération de restauration. Le format d’URL est utilisé pour la restauration des sauvegardes à partir du service de stockage Microsoft Azure.

Important

Pour restaurer à partir de plusieurs unités quand l’opération s’effectue depuis une URL, vous devez utiliser des jetons de signature d’accès partagé (SAP). Pour obtenir des exemples de signatures d’accès partagé, consultez Sauvegarde SQL Server vers une URL et Simplifying creation of SQL Credentials with Shared Access Signature (SAS) tokens on Azure Storage with PowerShell.

n Correspond à un espace réservé indiquant qu’il est possible de spécifier jusqu’à 64 unités de sauvegarde dans une liste séparée par des virgules.

Remarques

En tant que prérequis, vous devez créer une information d’identification avec un nom qui correspond à l’URL du compte de Stockage Blob et une Signature d’accès partagé placée en tant que secret. La commande RESTORE recherche les informations d’identification à l’aide de l’URL du compte de Stockage Blob afin de trouver les informations nécessaires pour lire l’appareil de sauvegarde.

L’opération RESTORE est asynchrone, la restauration continue même si la connexion cliente est rompue. Si votre connexion est supprimée, vous pouvez afficher la vue sys.dm_operation_status pour vérifier l’état d’une opération de restauration (et d’une opération CREATE ou DROP sur une base de données).

Les options de base de données suivantes sont définies/remplacées et ne peuvent pas être modifiées ultérieurement :

  • NEW_BROKER (si le service Broker n’est pas activé dans le fichier .bak)
  • ENABLE_BROKER (si le service Broker n’est pas activé dans le fichier .bak)
  • AUTO_CLOSE=OFF (si une base de données dans le fichier .bak est définie avec AUTO_CLOSE=ON)
  • RECOVERY FULL (si une base de données dans le fichier .bak est définie avec le mode de récupération SIMPLE ou BULK_LOGGED)
  • Un groupe de fichiers à mémoire optimisée, appelé XTP, est ajouté au fichier source .bak s’il n’y est pas déjà. Chaque groupe de fichiers à mémoire optimisée existant est renommé XTP
  • Les options SINGLE_USER et RESTRICTED_USER sont remplacées par l’option MULTI_USER

Limitations - SQL Managed Instance

Les limitations suivantes s’appliquent :

  • Les fichiers .bak contenant plusieurs jeux de sauvegarde ne peuvent pas être restaurés.
  • Les fichiers .bak contenant plusieurs fichiers journaux ne peuvent pas être restaurés.
  • La restauration échoue si le fichier .bak contient des données FILESTREAM.
  • Les sauvegardes contenant des bases de données avec des objets en mémoire actifs ne peuvent pas être restaurées au niveau de performance Usage général.
  • Les sauvegardes contenant des bases de données en mode lecture seule ne peuvent pas être restaurées.

Pour plus d’informations, consultez Azure SQL Managed Instance

Restauration d’une base de données chiffrée

Pour restaurer une base de données chiffrée, vous devez avoir accès au certificat ou à la clé asymétrique qui a servi à chiffrer la base de données. Sans le certificat et la clé asymétrique, la base de données ne peut pas être restaurée. En conséquence, le certificat utilisé pour chiffrer la clé de chiffrement de base de données doit être conservé tant que la sauvegarde est utile. Pour plus d'informations, consultez SQL Server Certificates and Asymmetric Keys.

Autorisations

L’utilisateur doit posséder les autorisations CREATE DATABASE afin de pouvoir exécuter RESTORE.

CREATE LOGIN mylogin WITH PASSWORD = 'Very Strong Pwd123!';
GRANT CREATE ANY DATABASE TO [mylogin];

Les autorisations RESTORE sont attribuées aux rôles dont les informations d'appartenance sont toujours immédiatement accessibles à partir du serveur. Étant donné que l’appartenance au rôle de base de données fixe ne peut être contrôlée que quand la base de données est accessible et non endommagée, ce qui n’est pas toujours le cas lorsque RESTORE est exécuté, les membres du rôle de base de données fixe db_owner ne détiennent pas d’autorisations RESTORE.

Exemples

Les exemples suivants restaurent une sauvegarde de base de données en copie seule à partir de l’URL, avec la création d’informations d’identification.

R. Restaurer la base de données à partir de quatre unités de sauvegarde

-- Create credential
CREATE CREDENTIAL [https://mybackups.blob.core.windows.net/wide-world-importers]
WITH IDENTITY = 'SHARED ACCESS SIGNATURE',
      SECRET = 'sv=2017-11-09&ss=bq&srt=sco&sp=rl&se=2022-06-19T22:41:07Z&st=2018-06-01T14:41:07Z&spr=https&sig=s7wddcf0w%3D';
GO
-- Restore database
RESTORE DATABASE WideWorldImportersStandard
FROM URL = N'https://mybackups.blob.core.windows.net/wide-world-importers/00-WideWorldImporters-Standard.bak',
URL = N'https://mybackups.blob.core.windows.net/wide-world-importers/01-WideWorldImporters-Standard.bak',
URL = N'https://mybackups.blob.core.windows.net/wide-world-importers/02-WideWorldImporters-Standard.bak',
URL = N'https://mybackups.blob.core.windows.net/wide-world-importers/03-WideWorldImporters-Standard.bak'

L’erreur suivante s’affiche si la base de données existe déjà : Msg 1801, Level 16, State 1, Line 9 Database 'WideWorldImportersStandard' already exists. Choose a different database name.

B. Restaurer la base de données spécifiée par le biais de la variable

DECLARE @db_name sysname = 'WideWorldImportersStandard';
DECLARE @url nvarchar(400) = N'https://mybackups.blob.core.windows.net/wide-world-importers/WideWorldImporters-Standard.bak';

RESTORE DATABASE @db_name
FROM URL = @url

C. Suivre la progression de l’instruction restore

SELECT query = a.text, start_time, percent_complete,
    eta = dateadd(second,estimated_completion_time/1000, getdate())
FROM sys.dm_exec_requests r
    CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) a
WHERE r.command = 'RESTORE DATABASE'

Notes

Cette vue affichera probablement deux requêtes restore. L’une est l’instruction RESTORE d’origine envoyée par le client, et l’autre est une instruction RESTORE en arrière-plan qui s’exécute même si la connexion du client échoue.

SQL Server

SQL Managed Instance

* Analytics
Platform System (PDW) *

 

Système de la plateforme d'analyse

Restaure une base de données utilisateur Analytics Platform System (PDW) à partir d’une sauvegarde de base de données vers une appliance Analytics Platform System (PDW). La base de données est restaurée à partir d’une sauvegarde créée précédemment par la commande Analytics Platform System (PDW) BACKUP DATABASE - Analytics Platform System. Les opérations de sauvegarde et de restauration vous permettent d’établir un plan de récupération d’urgence ou de déplacer des bases de données d’une appliance vers une autre.

Notes

La restauration de la base de données système master inclut la restauration des informations de connexion de l’appliance. Pour restaurer la base de données master, accédez à la page Restauration de la base de données MASTER de l’outil Configuration Manager. Un administrateur ayant accès au nœud de contrôle peut effectuer cette opération. Pour plus d’informations sur les sauvegardes de bases de données Analytics Platform System (PDW), consultez la section relative à la sauvegarde et à la restauration dans la Documentation du produit Analytics Platform System (PDW).

Syntaxe

-- Restore the master database
-- Use the Configuration Manager tool.

Restore a full user database backup.
RESTORE DATABASE database_name
    FROM DISK = '\\UNC_path\full_backup_directory'
[;]

--Restore a full user database backup and then a differential backup.
RESTORE DATABASE database_name
    FROM DISK = '\\UNC_path\differential_backup_directory'
    WITH [ ( ] BASE = '\\UNC_path\full_backup_directory' [ ) ]
[;]

--Restore header information for a full or differential user database backup.
RESTORE HEADERONLY
    FROM DISK = '\\UNC_path\backup_directory'
[;]

Arguments

RESTORE DATABASE database_name

Spécifie la restauration d’une base de données utilisateur dans une base de données appelée database_name. La base de données restaurée peut avoir un nom différent de la base de données source sauvegardée. database_name ne peut pas déjà exister en tant que base de données sur l’appliance de destination. Pour plus d’informations sur les noms de base de données autorisés, consultez « Règles de nommage des objets » dans la Documentation du produit Analytics Platform System (PDW).

La restauration d’une base de données utilisateur a pour effet de restaurer une sauvegarde complète de base de données et éventuellement de restaurer une sauvegarde différentielle dans l’appliance. La restauration d’une base de données utilisateur inclut la restauration des utilisateurs de la base de données, ainsi que les rôles de base de données.

FROM DISK = ’\\chemin_accès_UNC\répertoire_sauvegarde’

Chemin réseau et répertoire à partir desquels Analytics Platform System (PDW) doit restaurer les fichiers de sauvegarde. Par exemple, FROM DISK = '\\xxx.xxx.xxx.xxx\backups\2012\Monthly\08.2012.Mybackup'.

backup_directory Spécifie le nom d’un répertoire qui contient la sauvegarde complète ou différentielle. Par exemple, vous pouvez effectuer une opération RESTORE HEADERONLY sur une sauvegarde complète ou différentielle.

full_backup_directory Spécifie le nom d’un répertoire qui contient la sauvegarde complète.

differential_backup_directory Spécifie le nom du répertoire qui contient la sauvegarde différentielle.

  • Le chemin et le répertoire de sauvegarde doivent déjà exister et être spécifiés comme chemin UNC (Universal Naming Convention).
  • Le chemin du répertoire de sauvegarde ne peut pas être un chemin local ni un emplacement sur un nœud d’appliance Analytics Platform System (PDW).
  • La longueur maximale du chemin UNC et du nom du répertoire de sauvegarde est de 200 caractères.
  • Le serveur ou l’hôte doivent être spécifiés comme une adresse IP.

RESTORE HEADERONLY

Spécifie le retour des seules informations d’en-tête d’une sauvegarde de base de données utilisateur unique. L’en-tête comprend différents champs, notamment le texte descriptif de la sauvegarde et le nom de la sauvegarde. Le nom de la sauvegarde ne doit pas nécessairement être le même que celui du répertoire où sont stockés les fichiers de sauvegarde.

Les résultats de RESTORE HEADERONLY sont modélisés d’après les résultats de RESTORE HEADERONLY de SQL Server. Les résultats comportent plus de 50 colonnes, qui ne sont pas toutes utilisées par Analytics Platform System (PDW). Pour une description des colonnes présentes dans les résultats de RESTORE HEADERONLY de SQL Server, consultez l’article RESTORE HEADERONLY.

Autorisations

Nécessite l’autorisation CREATE ANY DATABASE.

Nécessite un compte Windows doté d’un droit d’accès et de lecture à partir du répertoire de sauvegarde. Vous devez aussi stocker le nom de compte et le mot de passe Windows dans Analytics Platform System (PDW).

Gestion des erreurs

La commande RESTORE DATABASE génère des erreurs dans les cas suivants :

  • Le nom de la base de données à restaurer existe déjà dans l’appliance cible. Pour éviter cela, choisissez un nom de base de données unique ou supprimez la base de données existante avant d’exécuter la restauration.
  • Le répertoire de sauvegarde contient un ensemble de fichiers de sauvegarde non valide.
  • Les autorisations de connexion ne sont pas suffisantes pour restaurer une base de données.
  • Analytics Platform System (PDW) ne dispose pas des autorisations appropriées pour accéder à l’emplacement réseau où se trouvent les fichiers de sauvegarde.
  • L’emplacement réseau du répertoire de sauvegarde n’existe pas ou n’est pas disponible.
  • Les nœuds de calcul ou le nœud de contrôle n’ont pas suffisamment d’espace disque. Analytics Platform System (PDW) ne confirme pas que l’appliance dispose d’une quantité d’espace disque suffisante avant le lancement de la restauration. De ce fait, il est possible qu’une erreur d’espace disque insuffisant soit générée pendant l’exécution de l’instruction RESTORE DATABASE. Quand l’espace disque est insuffisant, Analytics Platform System (PDW) annule la restauration.
  • L’appliance cible dans laquelle la base de données est restaurée compte moins de nœuds de calcul que l’appliance source à partir de laquelle la base de données a été sauvegardée.
  • La tentative de restauration de la base de données a pour cadre une transaction.

Notes

Analytics Platform System (PDW) suit la réussite des restaurations des bases de données. Avant de restaurer une sauvegarde différentielle de base de données, Analytics Platform System (PDW) vérifie que la restauration complète de base de données a abouti correctement.

Après une restauration, la base de données utilisateur présente le niveau de compatibilité de base de données 120. Cela vaut pour toutes les bases de données, quel que soit leur niveau de compatibilité d’origine.

Restauration dans une appliance dotée d’un plus grand nombre de nœuds de calcul

Exécutez DBCC SHRINKLOG (Azure Synapse Analytics) après avoir restauré une base de données d’une appliance vers une autre de plus grande taille, car la redistribution fera croître le journal des transactions.

Le fait de restaurer une sauvegarde dans une appliance dotée d’un plus grand nombre de nœuds de calcul a pour effet d’accroître la taille de la base de données allouée de façon proportionnelle au nombre de nœuds de calcul.

Par exemple, si vous restaurez une base de données de 60 Go d’une appliance à deux nœuds (30 Go par nœud) vers une appliance à six nœuds, Analytics Platform System (PDW) crée une base de données de 180 Go (six nœuds de 30 Go) dans l’appliance à six nœuds. Analytics Platform System (PDW) commence par restaurer la base de données sur 2 nœuds pour être en adéquation avec la configuration source, puis redistribue les données aux 6 nœuds.

À l’issue de la redistribution, chaque nœud de calcul contient moins de données réelles et plus d’espace libre que chaque nœud de calcul de l’appliance source de plus petite taille. Profitez de l’espace supplémentaire pour ajouter davantage de données à la base de données. Si la base de données restaurée est trop volumineuse, vous pouvez utiliser ALTER DATABASE - PDW pour réduire la taille des fichiers de base de données.

Limitations et restrictions

Dans le cadre de ces limitations et restrictions, l’appliance source est celle à partir de laquelle la sauvegarde de base de données a été créée, tandis que l’appliance cible est celle sur laquelle la base de données est restaurée.

  • À l’occasion d’une restauration de base de données, les statistiques ne sont pas régénérées automatiquement.
  • Seule une instruction RESTORE DATABASE ou BACKUP DATABASE peut s’exécuter dans l’appliance à un moment donné. Si plusieurs instructions de sauvegarde et de restauration sont envoyées simultanément, l’appliance les met en file d’attente et les traite l’une après l’autre.
  • Vous ne pouvez restaurer une sauvegarde de base de données que dans une appliance cible Analytics Platform System (PDW) qui compte au moins le même nombre de nœuds de calcul que l’appliance source. L’appliance cible ne peut pas contenir moins de nœuds de calcul que l’appliance source.
  • Une sauvegarde qui a été créée dans une appliance basée sur du matériel SQL Server 2012 PDW ne pas être restaurée dans une appliance basée sur du matériel SQL Server 2008 R2. Cela est vrai même si l’appliance a été acquise à l’origine avec du matériel SQL Server 2008 R2 PDW et exécute maintenant un logiciel SQL Server 2012 PDW.

Verrouillage

Applique un verrou exclusif sur l’objet DATABASE.

Exemples

R. Exemples simples RESTORE

L’exemple suivant restaure une sauvegarde complète dans la base de données SalesInvoices2013. Les fichiers de sauvegarde sont stockés dans le répertoire \\\xxx.xxx.xxx.xxx\backups\yearly\Invoices2013Full. La base de données SalesInvoices2013 ne doit pas déjà se trouver dans l’appliance cible, car cette commande échouerait avec une erreur.

RESTORE DATABASE SalesInvoices2013
FROM DISK = '\\xxx.xxx.xxx.xxx\backups\yearly\Invoices2013Full';

B. Restaurer une sauvegarde complète et différentielle

L’exemple suivant illustre la sauvegarde complète, puis la sauvegarde différentielle dans la base de données SalesInvoices2013.

La sauvegarde complète de la base de données est restaurée à partir de la sauvegarde complète, qui est stockée dans le répertoire \\\xxx.xxx.xxx.xxx\backups\yearly\Invoices2013Full. Si la restauration aboutit, la sauvegarde différentielle est restaurée dans la base de données SalesInvoices2013. La sauvegarde différentielle est stockée dans le répertoire \\\xxx.xxx.xxx.xxx\backups\yearly\Invoices2013Diff.

RESTORE DATABASE SalesInvoices2013
    FROM DISK = '\\xxx.xxx.xxx.xxx\backups\yearly\Invoices2013Diff'
    WITH BASE = '\\xxx.xxx.xxx.xxx\backups\yearly\Invoices2013Full'
[;]

C. Restauration de l’en-tête de sauvegarde

L’exemple suivant illustre la restauration des informations d’en-tête de la sauvegarde de base de données \\\xxx.xxx.xxx.xxx\backups\yearly\Invoices2013Full. La commande génère une ligne d’informations pour la sauvegarde Invoices2013Full.

RESTORE HEADERONLY
    FROM DISK = '\\xxx.xxx.xxx.xxx\backups\yearly\Invoices2013Full'
[;]

Vous pouvez vous servir des informations d’en-tête pour vérifier le contenu d’une sauvegarde ou pour vous assurer que l’appliance de restauration cible est compatible avec l’appliance de sauvegarde source avant d’entreprendre la restauration de la sauvegarde.

Étapes suivantes