Partager via

  • Article

RESTORE (Transact-SQL)

Restaure les sauvegardes réalisées à l'aide de la commande BACKUP. 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 de capture instantanée de base de données.

Pour plus d'informations sur les scénarios de restauration SQL Server, consultez Vue d'ensemble de la restauration et de la récupération (SQL Server) et Implémentation de scénarios de restauration pour les bases de données SQL Server.

[!REMARQUE]

Pour plus d'informations sur les descriptions des arguments, consultez Arguments RESTORE (Transact-SQL).

Icône Lien de rubriqueConventions de syntaxe Transact-SQL

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>
      | , <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 } = { '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 

--Backup Set Options
 | FILE = { backup_set_file_number | @backup_set_file_number } 
 | PASSWORD = { password | @password_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

<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 obtenir une description des arguments, consultez Arguments RESTORE (Transact-SQL).

Notes

Vous ne pouvez pas restaurer la sauvegarde d'une base de données compressée vers une base de données non compressée.

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.

Pour plus d'informations sur la récupération d'une base de données, consultez Fonctionnement de la restauration et de la récupération de sauvegardes dans SQL Server et Implémentation de scénarios de restauration pour les bases de données SQL Server.

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). Pour plus d'informations, consultez Réponse aux erreurs de restauration SQL Server provoquées par des sauvegardes endommagées.

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 est réalisée à l'aide d'une procédure spéciale. Pour plus d'informations, consultez Considérations relatives à la restauration de la base de données MASTER.

Les sauvegardes créées à l'aide de MicrosoftSQL Server ne peuvent pas être restaurées dans une version antérieure de SQL Server.

La restauration d'une base de données efface le cache de plan pour l'instance de SQL Server. 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. Depuis SQL Server 2005 Service Pack 2, pour chaque mémoire cache effacée dans le cache de plan, le journal des erreurs SQL Server contient le message d'information suivant : « SQL Server a rencontré %d occurrence(s) de vidages de mémoire cache pour la mémoire cache '%s' (partie du cache du plan) en raison d'opérations de maintenance ou de reconfiguration de base de données ». Ce message est enregistré toutes les cinq minutes si le cache est vidé au cours de cet intervalle.

La version de la base de données en cours de restauration doit être au moins la version 80 (SQL Server 2000) pour être restaurée sur SQL Server 2008. Les bases de données SQL Server 2000 ou SQL Server 2005 dont le niveau de compatibilité est inférieur à 80 seront définies avec la compatibilité 80 lorsqu'elles seront restaurées.

[!REMARQUE]

Après la restauration d'une base de données SQL Server 2005 ou SQL Server 2000 dans SQL Server 2008, la base de données est immédiatement disponible et est ensuite automatiquement mise à niveau. Si la base de données comprend des index de recherche en texte intégral, la mise à niveau les importe, les réinitialise ou les reconstruit, selon le paramètre 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. 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.

Scénarios de restauration

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

Mots clés RESTORE supprimés

Les mots clés suivants ont été supprimés dans SQL Server 2008 :

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

Exigences en matière de 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 Certificats et clés asymétriques SQL Server.

Bases de données activées pour le format de stockage vardecimal

Les sauvegardes et les restaurations fonctionnent correctement avec le format de stockage vardecimal. Pour plus d'informations sur le format de stockage vardecimal, consultez Stockage des données décimales sous forme de colonne de longueur variable.

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.

    Pour récupérer la base de données, le jeu de données complet restauré (le jeu de restauration par progression) doit être 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.

Rétablir 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.

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.

[!REMARQUE]

Les catalogues de texte intégral importés à partir de SQL Server 2005 ou SQL Server 2000 sont toujours traités en tant que fichiers de base de données. Pour ceux-ci, la procédure SQL Server 2005 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 dans la documentation en ligne de SQL Server 2005.

Paramètres de bases de données et restauration

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.

[!REMARQUE]

Ce comportement est différent de celui des versions de SQL Server antérieures à SQL Server 2000.

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.

Tables d'historique de sauvegarde et de restauration

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 Visualisation des informations concernant les sauvegardes.

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.

[!REMARQUE]

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 fichier journal après défaillance, avant la restauration de la base de données. Restaurer une base de données sans effectuer une sauvegarde de fichier journal après défaillance 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 fichier journal après défaillance, consultez Sauvegardes de fichier journal après défaillance.

Restauration en ligne

[!REMARQUE]

La restauration en ligne est autorisée uniquement dans SQL Server 2005 Enterprise Edition et versions ultérieures.

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.

[!REMARQUE]

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

Pour plus d'informations, consultez Réalisation de restauration en ligne.

Restauration fragmentaire

Cette nouvelle fonctionnalité de SQL Server 2005 améliore la restauration partielle MicrosoftSQL Server 2000. La restauration fragmentaire permet de restaurer des groupes de fichiers après avoir effectué une restauration partielle des groupes de fichiers primaires et de certains groupes de fichiers secondaires. Les groupes de fichiers qui ne sont pas restaurés sont marqués comme étant hors connexion et ne sont pas accessibles. Les groupes de fichiers hors connexion peuvent cependant être restaurés ultérieurement via une restauration de fichiers. Pour permettre la restauration de l'ensemble de la base de données par étape à des moments différents, la restauration fragmentaire effectue des contrôles pour garantir la cohérence finale de la base de données.

[!REMARQUE]

Dans SQL Server 2000, une restauration partielle ne peut être effectuée qu'à partir d'une sauvegarde de base de données complète. Cette restriction a été supprimée dans SQL Server 2005.

Si une séquence de restauration partielle exclut tout groupe de fichiers FILESTREAM, la restauration jusqu'à une date et heure n'est pas prise en charge. Vous pouvez imposer à la séquence de restauration de continuer. Toutefois, les groupes de fichiers FILESTREAM omis dans l'instruction RESTORE ne peuvent jamais être restaurés. Pour forcer une limite de restauration dans le temps, spécifiez l'option CONTINUE_AFTER_ERROR avec l'option STOPAT, STOPATMARK ou STOPBEFOREMARKx, que vous devez également spécifier dans vos instructions RESTORE LOG suivantes. Si vous spécifiez l'option CONTINUE_AFTER_ERROR, la séquence de restauration partielle réussit et le groupe de fichiers FILESTREAM devient irrécupérable.

Pour plus d'informations sur la restauration fragmentaire, consultez Exécution d'une restauration fragmentaire.

Restauration d'une base de données vers une capture instantanée 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 la capture instantanée de base de données de 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écise dans la capture instantanée de base de données spécifiée. Seule la capture instantanée vers laquelle 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 la capture instantanée. 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 la capture instantanée. Toutefois, le retour à une capture instantanée supprime tous les catalogues de texte intégral.

Le rétablissement à partir d'une capture instantanée de base de données n'est pas destiné à la récupération des supports. Contrairement à un jeu de sauvegarde classique, la capture instantanée 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 la capture instantanée est endommagée, le rétablissement à partir d'une capture instantanée 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 la capture instantanée.

  • Il existe plus d'une capture instantanée de la base de données.

Pour plus d'informations, consultez Retour à une capture instantanée de base de donné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 fixes 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 lorsque 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.

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'ajouts 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.

Remarque relative à la sécuritéRemarque relative à la sécurité

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 prochaine version de Microsoft 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é en matière de protection des sauvegardes consiste à stocker les bandes de sauvegarde dans un emplacement sûr ou à sauvegarder les fichiers disque protégés par une liste de contrôle d'accès (ACL). La liste de contrôle d'accès doit être définie à la racine du répertoire dans lequel les sauvegardes sont effectuées.

Exemples

[!REMARQUE]

La base de données AdventureWorks est fournie à titre indicatif. AdventureWorks est l'un des exemples de bases de données de SQL Server. Adventure Works Cycles est une société de fabrication fictive utilisée pour illustrer des scénarios et des concepts de base de données. Pour plus d'informations sur cette base de données, consultez Exemples de bases de données AdventureWorks.

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 :

  • A. Restauration d'une base de données complète

  • B. Restauration de sauvegardes complètes et différentielles d'une base de données

  • C. Restauration d'une base de données en utilisant la syntaxe RESTART

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

  • E. Copie d'une base de données en utilisant BACKUP et RESTORE

  • F. Restauration jusqu'à une date et heure en utilisant STOPAT

  • G. Restauration du journal des transactions jusqu'à une marque

  • H. Restauration en utilisant la syntaxe TAPE

  • I. Restauration en utilisant la syntaxe FILE et FILEGROUP

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

[!REMARQUE]

Pour voir d'autres exemples, consultez Exemples de séquences de restauration pour plusieurs scénarios de restauration ainsi que les rubriques de procédures de restauration qui sont répertoriées dans Rubriques sur les procédures de sauvegarde et de restauration (Transact-SQL).

A. Restauration d'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 voir un exemple de création de cette unité, consultez Unités de sauvegarde.

RESTORE DATABASE AdventureWorks 
   FROM AdventureWorksBackups

[!REMARQUE]

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 fichier journal après défaillance, avant la restauration de la base de données. Pour plus d'informations, consultez Sauvegardes de fichier journal après défaillance.

[Début des exemples]

B. Restauration de 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\AdventureWorks.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 AdventureWorks
   FROM DISK = 'Z:\SQLServerBackups\AdventureWorks.bak'
   WITH FILE = 6
      NORECOVERY;
RESTORE DATABASE AdventureWorks
   FROM DISK = 'Z:\SQLServerBackups\AdventureWorks.bak'
   WITH FILE = 9
      RECOVERY;

[Début des exemples]

C. Restauration d'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 AdventureWorks
   FROM AdventureWorksBackups
-- Here is the RESTORE RESTART operation.
RESTORE DATABASE AdventureWorks 
   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\MSSQL10.MSSQLSERVER\MSSQL\Data.

RESTORE DATABASE AdventureWorks
   FROM AdventureWorksBackups
   WITH NORECOVERY, 
      MOVE 'AdventureWorks_Data' TO 
'C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\Data\NewAdvWorks.mdf', 
      MOVE 'AdventureWorks_Log' 
TO 'C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\Data\NewAdvWorks.ldf'
RESTORE LOG AdventureWorks
   FROM AdventureWorksBackups
   WITH RECOVERY

[Début des exemples]

E. Copie d'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 AdventureWorks. 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 s'appelle TestDB. Pour plus d'informations, consultez RESTORE FILELISTONLY (Transact-SQL).

BACKUP DATABASE AdventureWorks 
   TO AdventureWorksBackups ;

RESTORE FILELISTONLY 
   FROM AdventureWorksBackups ;

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

[Début des exemples]

F. Restauration jusqu'à une date et heure en utilisant STOPAT

L'exemple suivant restaure une base de données dans l'état où elle se trouvait le April 15, 2020 à 12:00 AM 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 AdventureWorks
   FROM AdventureWorksBackups
   WITH FILE=3, NORECOVERY;

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

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

[Début des exemples]

G. Restauration du 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 AdventureWorks
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 AdventureWorks
FROM AdventureWorksBackups
WITH FILE = 3, NORECOVERY;
GO

RESTORE LOG AdventureWorks
   FROM AdventureWorksBackups 
   WITH FILE = 4,
   RECOVERY, 
   STOPATMARK = 'ListPriceUpdate';

[Début des exemples]

H. Restauration avec 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 AdventureWorks 
   FROM TAPE = '\\.\tape0'

[Début des exemples]

I. Restauration 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 restaurée la dernière sauvegarde de fichier journal, la base de données est récupérée.

[!REMARQUE]

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.

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 une capture instantanée de base de données. Il part du principe qu'une seule capture instantanée existe actuellement dans la base de données. Pour obtenir un exemple de création de cette capture instantanée de base de données, consultez Procédure : créer une capture instantanée de base de données (Transact-SQL).

[!REMARQUE]

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

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

Pour plus d'informations, consultez Retour à une capture instantanée de base de données.

[Début des exemples]