RESTORE (Transact-SQL)

Mis à jour : 12 décembre 2006

Restaure les sauvegardes réalisées à l'aide de la commande BACKUP. Cette commande vous permet d'effectuer les opérations suivantes :

  • 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, des groupes de fichiers ou des pages spécifiques dans une base de données (restauration de fichiers ou 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 la sauvegarde et la restauration d'une base de données, consultez Sauvegarde et restauration de bases de données dans SQL Server.

ms186858.note(fr-fr,SQL.90).gifRemarque :
Pour obtenir une description des arguments, consultez Arguments RESTORE (Transact-SQL).

Icône Lien de rubriqueConventions de la syntaxe de Transact-SQL

Syntaxe

--To restore a complete database from a full database backup (a Complete Restore):
RESTORE DATABASE { database_name | @database_name_var } 
[ FROM <backup_device> [ ,...n ] ]
[ WITH 
   [ { CHECKSUM | NO_CHECKSUM } ]
   [ [ , ] { STOP_ON_ERROR | CONTINUE_AFTER_ERROR } ]
   [ [ , ] FILE = { backup_set_file_number | @backup_set_file_number } ] 
   [ [ , ] KEEP_REPLICATION ] 
   [ [ , ] MEDIANAME = { media_name | @media_name_variable } ] 
   [ [ , ] MEDIAPASSWORD = { mediapassword |
                    @mediapassword_variable } ] 
   [ [ , ] MOVE 'logical_file_name_in_backup' TO 'operating_system_file_name' ] 
                [ ,...n ] 
   [ [ , ] PASSWORD = { password | @password_variable } ] 
    [ [ , ] BLOCKSIZE = { blocksize | @blocksize_variable } ] 
    [ [ , ] BUFFERCOUNT = { buffercount | @buffercount_variable } ] 
   [ [ , ]    MAXTRANSFERSIZE = { maxtransfersize | @maxtransfersize_variable } ] 
   [ [ , ] ENABLE_BROKER ] 
   [ [ , ] ERROR_BROKER_CONVERSATIONS ] 
   [ [ , ] NEW_BROKER ] 
   [ [ , ] { RECOVERY | NORECOVERY | STANDBY = 
          {standby_file_name | @standby_file_name_var } 
   } ] 
   [ [ , ] REPLACE ] 
   [ [ , ] RESTART ] 
   [ [ , ] RESTRICTED_USER ] 
   [ [ , ] { REWIND | NOREWIND } ] 
   [ [ , ] { UNLOAD | NOUNLOAD } ] 
   [ [ , ] STATS [ = percentage ] ] 
    [ [ , ] { STOPAT = { 'date_time' | @date_time_var } 
    |  STOPATMARK = { 'lsn:lsn_number' }
              [ AFTER 'datetime' ] 
    |  STOPBEFOREMARK = { 'lsn:lsn_number' }
             [ AFTER 'datetime' ]
   } ] 
]
[;]

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

--Restore part of a database (a partial restore):
RESTORE DATABASE { database_name | @database_name_var } 
  <files_or_filegroups> [ ,...n ] 
 [ FROM <backup_device> [ ,...n ] ] 
 [ WITH 
     PARTIAL 
   [ [ , ] { CHECKSUM | NO_CHECKSUM } ]
   [ [ , ] { STOP_ON_ERROR | CONTINUE_AFTER_ERROR } ]
   [ [ , ] FILE = { backup_set_file_number | @backup_set_file_number } ] 
   [ [ , ] MEDIANAME = { media_name | @media_name_variable } ] 
   [ [ , ] MEDIAPASSWORD = { mediapassword |
                      @mediapassword_variable } ] 
   [ [ , ] MOVE 'logical_file_name_in_backup' TO 'operating_system_file_name' ] 
                [ ,...n ] 
   [ [ , ] PASSWORD = { password | @password_variable } ] 
   [ [ , ] NORECOVERY ] 
   [ [ , ] REPLACE ] 
   [ [ , ] RESTART ] 
   [ [ , ] RESTRICTED_USER ]
   [ [ , ] { REWIND | NOREWIND } ] 
   [ [ , ] { UNLOAD | NOUNLOAD } ] 
   [ [ , ] STATS [=percentage ] ] 
   [ [ , ] { STOPAT = { 'date_time' | @date_time_var } 
    |  STOPATMARK = { 'lsn:lsn_number' }
              [ AFTER 'datetime' ] 
    |  STOPBEFOREMARK = { 'lsn:lsn_number' }
             [ AFTER 'datetime' ] 
   } ] 
]
[;]

<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
} 

--To Restore Specific Files, Filegroups, or Pages: 
RESTORE DATABASE { database_name | @database_name_var } 
     <file_or_filegroup_or_pages> [ ,...n ]
[ FROM <backup_device> [ ,...n ] ] 
[ WITH 
   [ { CHECKSUM | NO_CHECKSUM } ]
   [ [ , ] { STOP_ON_ERROR | CONTINUE_AFTER_ERROR } ]
   [ [ , ] FILE = { backup_set_file_number | @backup_set_file_number } ] 
   [ [ , ] MEDIANAME = { media_name | @media_name_variable } ] 

   [ [ , ] MEDIAPASSWORD = { mediapassword |
                      @mediapassword_variable } ]
   [ [ , ] MOVE 'logical_file_name_in_backup' TO 'operating_system_file_name' ] 
                [ ,...n ] 
   [ [ , ] PASSWORD = { password | @password_variable } ] 
   [ [ , ] NORECOVERY ] 
   [ [ , ] REPLACE ] 
   [ [ , ] RESTART ] 
   [ [ , ] RESTRICTED_USER ]
   [ [ , ] { REWIND | NOREWIND } ] 
   [ [ , ] { UNLOAD | NOUNLOAD } ] 
   [ [ , ] STATS [ =percentage ] ] 
]
[;]

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

<file_or_filegroup_or_pages> ::=
{ 
   FILE = { logical_file_name_in_backup | @logical_file_name_in_backup_var }
   | FILEGROUP = { logical_filegroup_name | @logical_filegroup_name_var } }
      | PAGE = 'file:page [ ,...n ]'  
} 

--To Restore a Transaction Log:
RESTORE LOG { database_name | @database_name_var } 
     [ <file_or_filegroup_or_pages> [ ,...n ] ]
[ FROM <backup_device> [ ,...n ] ] 
[ WITH 
   [ { CHECKSUM | NO_CHECKSUM } ]
   [ [ , ] { STOP_ON_ERROR | CONTINUE_AFTER_ERROR } ]
   [ [ , ] FILE = { backup_set_file_number | @backup_set_file_number } ] 
   [ [ , ] KEEP_REPLICATION ] 
   [ [ , ] MEDIANAME = { media_name | @media_name_variable } ] 
   [ [ , ] MEDIAPASSWORD = { mediapassword | @mediapassword_variable }      ]
   [ [ , ] MOVE 'logical_file_name_in_backup' TO 'operating_system_file_name' ] 
                [ ,...n ] 
   [ [ , ] PASSWORD = { password | @password_variable } ] 
   [ [ , ] { RECOVERY | NORECOVERY | STANDBY = 
          {standby_file_name | @standby_file_name_var } }
   ] 
   [ [ , ] REPLACE ] 
   [ [ , ] RESTART ] 
   [ [ , ] RESTRICTED_USER ]
   [ [ , ] { REWIND | NOREWIND } ] 
   [ [ , ] { UNLOAD | NOUNLOAD } ] 
   [ [ , ] STATS [=percentage ] ] 
   [ [ , ] { STOPAT = { 'date_time' | @date_time_var } 
    |  STOPATMARK = { 'mark_name' | 'lsn:lsn_number' }
              [ AFTER 'datetime' ] 
    |  STOPBEFOREMARK = { 'mark_name' | 'lsn:lsn_number' }
             [ AFTER 'datetime' ] 
   } ] 
]
[;]

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

<file_or_filegroup_or_pages> ::=
{ 
   FILE = { logical_file_name_in_backup | @logical_file_name_in_backup_var }
   | FILEGROUP = { logical_filegroup_name | @logical_filegroup_name_var } }
      | PAGE = 'file:page [ ,...n ]'  
} 

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

Arguments

Pour obtenir une description des arguments, consultez Arguments RESTORE (Transact-SQL).

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.

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 sur la restauration de la base de données master.

Les sauvegardes créées à l'aide de Microsoft SQL Server 2005 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. Dans SQL Server 2005 Service Pack 2, pour chaque mémoire cache effacée du cache du plan, le journal des erreurs de 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.

Scénarios de restauration

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

Compatibilité ascendante

Les mots clés suivants peuvent être utilisés dans la syntaxe de l'instruction RESTORE pour garantir la compatibilité ascendante :

  • Le mot clé LOAD peut être utilisé à la place de RESTORE.
  • Le mot clé TRANSACTION peut être utilisé à la place de LOG.
  • Le mot clé DBO_ONLY peut être utilisé à la place de RESTRICTED_USER.

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

Les opérations de sauvegarde et de restauration fonctionnent correctement avec le format de stockage vardecimal, mais le Moteur de base de données doit être mis à niveau vers SQL Server 2005 Service Pack 2 au minimum. Vous ne pouvez pas restaurer la sauvegarde d'une base de données compressées vers une base de données non compressée. Vous ne pouvez pas non plus restaurer une base de données d'une base de données d'un Service Pack 2 compressé vers une version antérieure de SQL Server. 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 dataset complet restauré (le jeu de restauration par progression) doit être cohérent avec 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 avec la base de données et que 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

Dans SQL Server 2005, 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. L'opération de restauration traite les catalogues de texte intégral comme des fichiers. 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.

ms186858.note(fr-fr,SQL.90).gifRemarque :
Vous ne pouvez pas restaurer un catalogue de texte intégral dans le répertoire racine.

Pour plus d'informations, consultez Sauvegarde et restauration de catalogues de texte intégral.

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.

ms186858.note(fr-fr,SQL.90).gifRemarque :
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

Introduite par SQL Server 2005, l'instruction 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 du journal dans un fichier qui a été ajouté à la base de données.

ms186858.note(fr-fr,SQL.90).gifRemarque :
Pour une base de données en mode de récupération utilisant les journaux de transactions, SQL Server 2005 nécessite, dans la plupart des cas, une sauvegarde de la fin du journal avant la restauration de la base de données. Restaurer une base de données sans sauvegarder la fin du journal au préalable entraîne une erreur, sauf si l'instruction RESTORE contient la clause WITH REPLACE ou WITH STOPAT. Pour plus d'informations sur la restauration de la fin du journal, consultez Sauvegardes de fichier journal après défaillance.

Restauration en ligne

ms186858.note(fr-fr,SQL.90).gifRemarque :
La restauration en ligne n'est autorisée que dans SQL Server 2005 Enterprise Edition.

Si la restauration en ligne est prise en charge et que 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.

ms186858.note(fr-fr,SQL.90).gifRemarque :
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 Microsoft SQL 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 par le biais d'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.

ms186858.note(fr-fr,SQL.90).gifRemarque :
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 est supprimée dans SQL Server 2005.

Pour plus d'informations, 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 au point dans le temps géré 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 recrée 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 régulier, 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 corruption.

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 compressés ou en lecture seule.
  • 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 de 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 de qualité de membre sont toujours immédiatement accessibles à partir du serveur. Étant donné que la qualité de membre de 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ée, les membres du rôle de base de données fixe db_owner ne détiennent pas les autorisations RESTORE.

Une opération de sauvegarde peut spécifier des mots de passe pour un support de sauvegarde, un jeu de sauvegarde ou pour les deux. Si un mot de passe est défini dans un support de sauvegarde ou un jeu de sauvegarde, vous devez spécifier le ou les mots de passe appropriés dans l'instruction RESTORE. Ces mots de passe empêchent les opérations non autorisées de restauration et d'ajouts de jeux de sauvegardes au support par le biais des outils SQL Server 2005. Cependant, les supports protégés par un mot de passe peuvent être remplacés par l'option FORMAT de l'instruction BACKUP.

ms186858.security(fr-fr,SQL.90).gifRemarque 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 2005. En aucun cas, il n'empêche la lecture des données de la sauvegarde par d'autres moyens ou le remplacement du mot de passe. La méthode de protection des sauvegardes conseillée 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

ms186858.note(fr-fr,SQL.90).gifRemarque :
La base de données AdventureWorks est fournie à titre indicatif. AdventureWorks est l'un des exemples de bases de données de SQL Server 2005. 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 et exemples de base de données.

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 dans le temps 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
ms186858.note(fr-fr,SQL.90).gifRemarque :
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
ms186858.note(fr-fr,SQL.90).gifRemarque :
Pour une base de données en mode de récupération utilisant les journaux de transactions, SQL Server 2005 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 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\MSSQL.1\MSSQL\Data.

RESTORE DATABASE AdventureWorks
   FROM AdventureWorksBackups
   WITH NORECOVERY, 
      MOVE 'AdventureWorks_Data' TO 
'C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data\NewAdvWorks.mdf', 
      MOVE 'AdventureWorks_Log' 
TO 'C:\Program Files\Microsoft SQL Server\MSSQL.1\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 réaliser une copie de la base de données AdventureWorks. L'instruction MOVE entraîne la restauration des données et du fichier journal dans des 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 dans le temps 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 journaux et plusieurs unités de sauvegarde.

RESTORE DATABASE AdventureWorks
   FROM AdventureWorksBackups
   WITH NORECOVERY;

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

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

[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 de type 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 restauration complète.

La sauvegarde de la base de données est le neuvième jeu de sauvegarde dans le jeu de médias sur une unité de sauvegarde logique nommée MyDatabaseBackups. Ensuite, trois sauvegardes de fichier journal, qui se trouvent dans les trois jeux de sauvegarde suivants (10, 11 et 12) sur l'unité MyDatabaseBackups sont 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.

ms186858.note(fr-fr,SQL.90).gifRemarque :
La récupération est réalisée séparément afin d'éviter qu'elle n'ait lieu 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 fichier logique 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 jeu de médias. Par conséquent, sa position dans le jeu de médias est indiquée à l'aide de 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éation d'une capture instantanée de base de données (Transact-SQL).

ms186858.note(fr-fr,SQL.90).gifRemarque :
Le retour à 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]

Voir aussi

Référence

BACKUP (Transact-SQL)
RESTORE REWINDONLY (Transact-SQL)
RESTORE VERIFYONLY (Transact-SQL)

Autres ressources

Sauvegarde et restauration de catalogues de texte intégral
Sauvegarde et restauration de bases de données répliquées
Implémentation de scénarios de restauration pour les bases de données SQL Server
Supports, familles et jeux de sauvegarde
Fonctionnement de la restauration et de la récupération de sauvegardes dans SQL Server
Visualisation des informations concernant les sauvegardes

Aide et Informations

Assistance sur SQL Server 2005

Historique des modifications

Version Historique

12 décembre 2006

Nouveau contenu :
  • Ajout des options BLOCKSIZE, BUFFERCOUNT et MAXTRANSFERSIZE dans la section Syntaxe.
  • Correction de la syntaxe STOPATMARK et STOPBEFOREMARK pour RESTORE DATABASE.
  • Ajout d'une section aux remarques sur la restauration des bases de données SQL Server 2005 Service Pack 2 activées pour le format de stockage vardecimal.
  • Ajout d'une section aux Notes sur l'effacement du cache de plan.
Contenu modifié :
  • Correction de la syntaxe de STOPAT, STOPATMARK et STOPBEFOREMARK.

14 avril 2006

Contenu modifié :
  • Clarification de la restriction liée aux captures instantanées de base de données pour les fichiers hors connexion.
  • La syntaxe logical_file_name de la variable du nom logique d'un fichier sauvegardé a été remplacée par logical_file_name_in_backup.