Arguments RESTORE (Transact-SQL)

Mis à jour : 12 décembre 2006

Cette rubrique documente les arguments qui sont décrits dans la section « Syntaxe » de l'instruction RESTORE {DATABASE|LOG} et des instructions auxiliaires associées : RESTORE FILELISTONLY, RESTORE HEADERONLY, RESTORE LABELONLY, RESTORE REWINDONLY et RESTORE VERIFYONLY. La plupart des arguments sont pris en charge uniquement par un sous-ensemble de ces six instructions. La prise en charge de chaque argument est indiquée dans la description de l'argument.

Conventions de la syntaxe de Transact-SQL

Syntaxe

Pour la syntaxe, consultez les rubriques suivantes :

• RESTORE (Transact-SQL)
• RESTORE FILELISTONLY (Transact-SQL)
• RESTORE HEADERONLY (Transact-SQL)
• RESTORE LABELONLY (Transact-SQL)
• RESTORE REWINDONLY (Transact-SQL)
• RESTORE VERIFYONLY (Transact-SQL)

Arguments

• BASE DE DONNÉES

  Remarque :
  Pris en charge par RESTORE.

  Spécifie la base de données cible. Si une liste de fichiers et de groupes de fichiers est fournie, seuls ceux-là seront restaurés.

  Pour une base de données en mode de récupération utilisant les journaux de transactions, Microsoft 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. La restauration d'une base de données sans la sauvegarde préalable du fichier journal engendre une erreur, sauf si l'instruction RESTORE contient la clause WITH REPLACE ou WITH STOPAT. Pour plus d'informations sur les sauvegardes de fichier journal, consultez Sauvegardes de fichier journal après défaillance.

• LOG

  Remarque :
  Pris en charge par RESTORE.

  Spécifie qu'une sauvegarde du journal des transactions doit être appliquée à cette base de données. Les journaux de transactions doivent être sollicités dans un ordre séquentiel. SQL Server vérifie le journal des transactions sauvegardé pour s'assurer que les transactions vont être chargées dans la base de données correcte et dans l'ordre adéquat. Pour appliquer plusieurs journaux de transactions, utilisez l'option NORECOVERY sur toutes les opérations de restauration sauf la dernière.

  Remarque :

  En général, le dernier journal restauré est la sauvegarde du fichier journal. Une sauvegarde de fichier journal est une sauvegarde du journal effectuée juste avant la restauration d'une base de données, généralement après un échec sur la base de données. L'utilisation d'une sauvegarde de fichier journal à partir d'une base de données probablement endommagée empêche la perte de travail en capturant le journal qui n'a pas encore été sauvegardé (la fin du journal). Pour plus d'informations, consultez Sauvegardes de fichier journal après défaillance.

  Pour plus d'informations, consultez Utilisation des sauvegardes de journaux de transactions.

• { database_name | **@**database_name_var}

  Remarque :
  Pris en charge par RESTORE.

  Base de données dans laquelle est restaurée la base complète ou le journal des transactions. Fourni comme variable (**@database_name_var), ce nom peut être spécifié comme constante de chaîne (@**database_name_var = database_name) ou comme variable de type chaîne de caractères, sauf pour les types de données ntext ou text.

• <file_or_filegroup_or_page> [ ,...n ]

  Remarque :
  Pris en charge par RESTORE.

  Spécifie le nom d'un fichier, d'un groupe de fichiers ou d'une page logique à inclure dans une instruction RESTORE DATABASE ou RESTORE LOG. Vous pouvez spécifier une liste de fichiers ou de groupes de fichiers.

  Pour une base de données qui utilise le mode de récupération simple, les options FILE et FILEGROUP sont autorisées uniquement si les fichiers ou groupes de fichiers cibles sont en lecture seule ou qu'il s'agit d'une restauration PARTIAL (qui aboutit à un groupe de fichiers obsolète).

  ?Pour une base de données utilisant le mode de restauration complète ou le mode de récupération utilisant les journaux de transactions, après l'utilisation de RESTORE DATABASE pour restaurer un ou plusieurs fichiers, groupes de fichiers, et/ou pages, en général, vous devez appliquer le journal des transactions aux fichiers contenant les données restaurées ; l'application du journal assure la cohérence de ces fichiers avec le reste de la base de données. Les exceptions sont les suivantes :

  • Si les fichiers en cours de restauration étaient en lecture seule avant leur dernière sauvegarde, alors il n'est pas nécessaire d'appliquer un journal des transactions et l'instruction RESTORE vous informe de cette situation.
  • Si la sauvegarde contient le groupe de fichiers principal et qu'une restauration partielle est entreprise. Dans ce cas, le journal des restaurations n'est pas nécessaire car le journal est restauré automatiquement à partir du jeu de sauvegarde.
  • FILE = { logical_file_name_in_backup| **@**logical_file_name_in_backup_var}
    Désigne un fichier à inclure dans la restauration de la base de données.

  • FILEGROUP = { logical_filegroup_name | **@**logical_filegroup_name_var }
    Désigne un groupe de fichiers à inclure dans la restauration de la base de données.

    Remarque   FILEGROUP est autorisé en mode de récupération simple uniquement si le groupe de fichiers spécifié est en lecture seule et qu'il s'agit d'une restauration partielle (si WITH PARTIAL est utilisé). Tout groupe de fichiers en lecture/écriture non restauré est indiqué dans un état défunt et ne peut être ensuite restauré dans la base de données résultante.

  • READ_WRITE_FILEGROUPS
    Sélectionne tous les groupes de fichiers en lecture/écriture. Cette option s'avère particulièrement utile lorsque vous disposez de groupes de fichiers en lecture seule à restaurer après des groupes de fichiers en lecture/écriture et avant les groupes de fichiers en lecture seule.

  • PAGE = 'file:page [ ,...n ]'
    Spécifie une liste d'une ou plusieurs pages pour une restauration de pages (disponible uniquement pour les bases de données qui utilisent le mode de restauration complète ou le mode de récupération utilisant les journaux de transactions). Les valeurs sont les suivantes :

    • PAGE
      Indique une liste d'un ou plusieurs fichiers et d'une ou plusieurs pages.
    • file
      ID du fichier contenant une page spécifique à restaurer.
    • page
      ID de la page à restaurer dans le fichier.

    • n
      Espace réservé indiquant que plusieurs pages peuvent être spécifiées.

      Le nombre maximal de pages pouvant être restaurées dans n'importe quel fichier unique au cours d'une séquence de restauration est 1000. Cependant, si vous disposez d'un nombre de pages endommagées plus important dans un fichier, pensez à restaurer la totalité du fichier au lieu des pages en question.

    Pour plus d'informations sur les restaurations de pages, consultez Restauration de pages.

  • [ ,...n ]
    Espace réservé indiquant qu'il est possible de spécifier plusieurs fichiers, groupes de fichiers et pages dans une liste séparée par des virgules. Le nombre est illimité.

• FROM { <backup_device> [ ,...n ] | <database_snapshot> }
  En général, spécifie les unités de sauvegarde à partir desquelles effectuer la restauration. Sinon, dans une instruction RESTORE DATABASE, la clause FROM peut spécifier le nom d'un cliché de base de données vers lequel vous restaurez la base de données, auquel cas, aucune clause WITH n'est autorisée.

  Si la clause FROM est omise, la restauration de la sauvegarde n'a pas lieu. À la place, la base de données est récupérée. Cela vous permet de récupérer une base de données restaurée avec l'option NORECOVERY, ou de basculer vers un serveur de secours. Si la clause FROM est omise, il convient de spécifier NORECOVERY, RECOVERY ou STANDBY dans la clause WITH.

  • <backup_device> [ ,...n ]
    Spécifie les unités de sauvegarde logiques ou physiques à utiliser pour l'opération de restauration.

    Remarque :
    Pris en charge par l'ensemble des six instructions : RESTORE, RESTORE FILELISTONLY, RESTORE HEADERONLY, RESTORE LABELONLY, RESTORE REWINDONLY et RESTORE VERIFYONLY.

    • <backup_device>::=
      Spécifie une unité de sauvegarde logique ou physique à utiliser pour l'opération de sauvegarde de la manière suivante :

      • { logical_backup_device_name | **@logical_backup_device_name_var }
        Nom logique, qui doit respecter les règles applicables aux identificateurs, de l'unité de sauvegarde créée par sp_addumpdevice et à partir de laquelle est restaurée la base de données. Fourni comme variable (@logical_backup_device_name_var), le nom de l'unité peut être spécifié comme constante de chaîne (@**logical_backup_device_name_var = logical_backup_device_name) ou comme variable de type chaîne de caractères, sauf pour les types de données ntext et text.

      • {DISK | TAPE } = { 'physical_backup_device_name' | **@physical_backup_device_name_var }
        Permet la restauration de sauvegardes à partir de l'unité de disque ou de bande spécifiée. Les types d'unité DISK et TAPE doivent être spécifiés avec le nom réel de l'unité (par exemple, le chemin complet et le nom de fichier). DISK = 'C:\Program Files\Microsoft SQL Server\MSSQL\BACKUP\Mybackup.bak' ou TAPE = '\\.\TAPE0'. Fourni comme variable (@physical_backup_device_name_var), le nom de l'unité de sauvegarde peut être spécifié comme constante de chaîne (@**physical_backup_device_name_var = physcial_backup_device_name) ou comme variable de type chaîne de caractères, sauf pour les types de données ntext et text.

        Si vous utilisez un serveur de réseau avec un nom UNC (qui doit contenir un nom d'ordinateur), spécifiez le type d'unité de disque. Pour plus d'informations sur l'utilisation des noms UNC, consultez Unités de sauvegarde.

        Le compte sous lequel vous exécutez SQL Server doit disposer d'un accès en lecture (READ) au serveur de réseau ou à l'ordinateur distant pour effectuer une opération RESTORE.

    • n
      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.

      Pour savoir si une séquence de restauration nécessite autant d'unités de sauvegarde que celles utilisées pour créer le support de sauvegarde auquel appartiennent les sauvegardes, vous devez tenir compte du fait que la restauration s'effectue hors connexion ou bien en ligne, conformément à ce qui suit :

      • La restauration hors connexion permet de restaurer une sauvegarde avec moins d'unités que celles utilisées pour créer la sauvegarde.
      • La restauration hors connexion nécessite toutes les unités de sauvegarde de la sauvegarde. Échec d'une tentative de restauration avec moins d'unités.

      Étudions, par exemple, un cas dans lequel une base de données a été sauvegardée sur quatre lecteurs de bande reliés au serveur. Une restauration en ligne nécessite que vous disposiez de quatre lecteurs de bande connectés au serveur ; une restauration hors connexion vous permet de restaurer la sauvegarde si l'ordinateur comprend moins de quatre lecteurs.

      Pour plus d'informations, consultez Utilisation de supports de sauvegarde dans SQL Server.

    Remarque :

    Lors de la restauration d'une sauvegarde à partir d'un support de sauvegarde miroir, vous ne pouvez spécifier qu'un seul miroir pour chaque famille de supports. En cas d'erreurs, cependant, l'utilisation d'autres miroirs permet une résolution rapide de certains problèmes de restauration. Vous pouvez remplacer un volume de support endommagé par un volume correspondant à partir d'un autre miroir. Sachez que pour les restaurations hors connexion, vous pouvez effectuer la restauration à partir d'un nombre de supports inférieur au nombre de familles de supports, mais que chaque famille n'est traitée qu'une seule fois.

  • <database_snapshot>::=

    Remarque :
    Pris en charge par RESTORE {DATABASE}.

    • DATABASE_SNAPSHOT **=**database_snapshot_name
      Rétablit la base de données selon la capture instantanée de base de données spécifiée par database_snapshot_name. L'option DATABASE_SNAPSHOT est disponible uniquement pour une restauration de base de données complète. Lors d'une opération de rétablissement, la capture instantanée de la base de données remplace une sauvegarde de base de données complète.

      Une opération de rétablissement nécessite que l'instantané de base de données spécifié soit l'unique sur la base de données. Au cours de l'opération de restauration, l'instantanée de base de données et la base de données de destination sont toutes deux indiquées comme In restore. Pour plus d'informations, consultez la section « Remarques » de la rubrique RESTORE {DATABASE}.

WITH <with_options> ::=

Spécifie les options à utiliser lors de l'opération de restauration. Pour obtenir un résumé permettant de savoir quelles instructions utilisent quelle option, consultez « Résumé de prise en charge des options WITH », plus loin dans ce chapitre.

• PARTIAL

  Remarque :
  Pris en charge uniquement par RESTORE {DATABASE}.

  Spécifie une opération de restauration partielle qui restaure le groupe de fichiers primaire et tout groupe de fichiers secondaire indiqué. L'option PARTIAL sélectionne implicitement le groupe de fichiers primaire, en spécifiant que FILEGROUP = 'PRIMARY' n'est pas nécessaire. Pour restaurer un groupe de fichiers secondaire, vous devez explicitement spécifier le groupe de fichiers à l'aide de l'option FILE ou de l'option FILEGROUP.

  L'option PARTIAL n'est pas autorisée sur des instructions RESTORE LOG.

  En commençant avec SQL Server 2005, l'option PARTIAL démarre l'étape initiale d'une restauration fragmentaire, qui permet la restauration ultérieure des groupes de fichiers restants. Pour plus d'informations, consultez Exécution d'une restauration fragmentaire.

  Remarque :

  La phase initiale d'une restauration fragmentaire remplace la restauration de base de données partielle de Microsoft SQL Server 2000. Une restauration de base de données partielle a été conçue pour restaurer uniquement une partie endommagée de la base de données (un sous-ensemble de groupes de fichiers) à un nouvel emplacement, afin que les données endommagées ou manquantes puissent être recopiées dans la base de données d'origine. Une base de données partiellement restaurée n'est pas destinée à une utilisation en tant que base de données de production, et pour améliorer les performances, RESTORE a ignoré un nombre important de vérifications de sécurité normales. Cependant, dans SQL Server 2005, l'option PARTIAL effectue ces vérification de sécurité.

• { CHECKSUM | NO_CHECKSUM }

  Remarque :
  Pris en charge par RESTORE, RESTORE FILELISTONLY, RESTORE HEADERONLY, RESTORE LABELONLY et RESTORE VERIFYONLY.

  Le comportement par défaut consiste à vérifier des sommes de contrôle si elles sont présentes et à poursuivre sans vérification si elles ne le sont pas.

  • CHECKSUM
    Spécifie que des sommes de contrôle de sauvegarde doivent être vérifiées et, si la sauvegarde manque de sommes de contrôle de sauvegarde, entraîne l'échec de l'opération de restauration avec un message indiquant que des sommes de contrôle ne sont pas présentes.

    Par défaut, lors de la détection d'une somme de contrôle incorrecte, RESTORE signale une erreur de somme de contrôle et s'arrête. Cependant, si vous spécifiez CONTINUE_AFTER_ERROR, RESTORE continue après le renvoi d'une erreur de somme de contrôle et du numéro de la page contenant la somme de contrôle incorrecte, si la corruption le permet.

    Les sommes de contrôle de sauvegarde sont nouvelles dans SQL Server 2005. Pour plus d'informations sur l'utilisation des sommes de contrôle de sauvegarde, consultez Détection et traitement des erreurs de support.

  • NO_CHECKSUM
    Désactive explicitement la validation de sommes de contrôle par l'opération de restauration.

• { STOP_ON_ERROR | CONTINUE_AFTER_ERROR }

  Remarque :
  Pris en charge par RESTORE, RESTORE FILELISTONLY, RESTORE HEADERONLY, RESTORE LABELONLY et RESTORE VERIFYONLY.

  • STOP_ON_ERROR
    Spécifie que l'opération de restauration s'arrête à la première erreur rencontrée. Il s'agit du comportement par défaut pour RESTORE, sauf pour VERIFYONLY qui possède CONTINUE_AFTER_ERROR par défaut.

  • CONTINUE_AFTER_ERROR
    Spécifie que l'opération de restauration doit continuer après la détection d'une erreur.

    Pour plus d'informations sur la continuation malgré des erreurs, consultez Réponse aux erreurs de restauration SQL Server provoquées par des sauvegardes endommagées.

    Si une sauvegarde contient des pages endommagées, il est préférable de répéter l'opération de restauration en utilisant une autre sauvegarde qui ne contient pas d'erreurs, par exemple, une sauvegarde effectuée avant que les pages ne soient endommagées. Toutefois, en dernier ressort, vous pouvez restaurer une sauvegarde endommagée à l'aide de l'option CONTINUE_AFTER_ERROR de l'instruction RESTORE et tenter de sauver les données.

• FILE ={ backup_set_file_number | **@**backup_set_file_number }

  Remarque :
  Pris en charge par RESTORE, RESTORE FILELISTONLY, RESTORE HEADERONLY et RESTORE VERIFYONLY.

  Identifie le jeu de sauvegardes à restaurer. Ainsi, la valeur 1 de backup_set_file_number peut indiquer le premier jeu de sauvegarde sur le support, et la valeur 2 le second jeu.

  Lorsque la valeur n'est pas spécifiée, celle par défaut est 1, sauf pour RESTORE HEADERONLY auquel cas tous les jeux de sauvegarde dans le support de sauvegarde sont traités. Pour plus d'informations, consultez « Spécification d'un jeu de sauvegarde » plus loin dans cette rubrique.

  Important :
  Cette option FILE n'a pas de rapport avec l'option FILE permettant de spécifier un fichier de base de données (FILE = { logical_file_name_in_backup | @logical_file_name_in_backup_var }).

• KEEP_REPLICATION

  Remarque :
  Pris en charge uniquement par RESTORE.

  Vous devez utiliser KEEP_REPLICATION lorsque vous intégrez l'envoi de journaux dans la configuration de la réplication. Cette option évite la suppression des paramètres de réplication lorsqu'une sauvegarde de base de données ou de journal est restaurée sur un serveur en état de secours semi-automatique et que la base de données est récupérée. Il est impossible de spécifier cette option lors de la restauration d'une sauvegarde avec l'option NORECOVERY. Pour garantir un fonctionnement correct de la réplication après la restauration :

  • Les bases de données msdb et master sur le serveur en état de secours semi-automatique doivent être synchronisées avec les bases de données msdb et master sur le serveur primaire.
  • Le serveur en état de secours semi-automatique doit être renommé pour utiliser le même nom que le serveur primaire.

• LOADHISTORY

  Remarque :
  Pris en charge par RESTORE VERIFYONLY.

  Indique que l'opération de restauration charge les informations dans les tables d'historique msdb. Pour le jeu de sauvegardes en cours de vérification, l'option LOADHISTORY transfère les informations sur les sauvegardes SQL Server stockées sur le support de sauvegarde dans les tables d'historique de restauration et de sauvegarde de la base de données msdb. Pour plus d'informations sur les tables d'historique, consultez Tables système (Transact-SQL).

• MEDIANAME = { media_name | **@**media_name_variable}

  Remarque :
  Pris en charge par RESTORE, RESTORE FILELISTONLY, RESTORE HEADERONLY, RESTORE LABELONLY et RESTORE VERIFYONLY.

  Indique le nom du support. S'il est fourni, le nom du support doit correspondre au nom des volumes de sauvegarde ; sinon, l'opération de restauration prend fin. En l'absence de nom de support dans l'instruction RESTORE, aucun contrôle n'a lieu pour vérifier la correspondance des noms de support sur les volumes de sauvegarde.

  Important :
  L'emploi cohérent de noms de support dans les opérations de sauvegarde et de restauration offre une garantie supplémentaire de sécurité lors du choix des supports de restauration.

• MEDIAPASSWORD = { mediapassword | **@**mediapassword_variable }

  Remarque :
  Pris en charge par RESTORE, RESTORE FILELISTONLY, RESTORE HEADERONLY, RESTORE LABELONLY et RESTORE VERIFYONLY.

  Fournit le mot de passe du support de sauvegarde. Un mot de passe de jeu de supports est une chaîne de caractères.

  Si un mot de passe a été fourni lors du formatage du support de sauvegarde, il est requis pour accéder à tout jeu de sauvegarde sur le jeu de supports. La spécification d'un mot de passe incorrect ou d'un mot de passe pour un support de sauvegarde qui n'en possède pas constitue une erreur.

  Important :
  Ce mot de passe fournit uniquement une protection faible pour le support de sauvegarde. Pour plus d'informations, consultez la section « Autorisations » pour la rubrique adéquate.

  Remarque :
  Cette option MEDIAPASSWORD sera supprimée dans une version ultérieure.

• MOVE 'logical_file_name_in_backup' TO 'operating_system_file_name' [ ...*n *]

  Remarque :
  Pris en charge par RESTORE et RESTORE VERIFYONLY.

  Indique que le fichier de données ou journal dont le nom logique est spécifié par logical_file_name_in_backup doit être déplacé par le biais d'une restauration dans l'emplacement défini par operating_system_file_name. Le nom de fichier logique d'un fichier de données ou journal dans un jeu de sauvegarde correspond au nom logique qu'il portait dans la base de données au moment de la création du jeu de sauvegarde.

  n est un espace réservé indiquant que vous pouvez spécifier des instructions MOVE supplémentaires. Spécifiez une instruction MOVE pour chaque fichier logique à restaurer à partir du jeu de sauvegarde dans un nouvel emplacement. Par défaut, le fichier logical_file_name_in_backup est restauré dans son emplacement d'origine.

  Remarque :
  Utilisez RESTORE FILELISTONLY pour obtenir une liste des fichiers logiques contenus dans le jeu de sauvegarde.

  Si une instruction RESTORE est utilisée pour déplacer une base de données sur le même serveur ou la copier sur un serveur différent, l'option MOVE peut s'avérer nécessaire afin de déplacer les fichiers de la base et d'éviter toute collision avec des fichiers existants.

  Utilisée avec RESTORE LOG, l'option MOVE ne peut servir qu'à déplacer les fichiers qui ont été ajoutés au cours de l'intervalle couvert par le journal en cours de restauration. Si, par exemple, la sauvegarde du journal contient une opération d'ajout de fichier pour le fichier file23, ce fichier peut être déplacé à 'laide de l'option MOVE sur RESTORE LOG.

  Si une instruction RESTORE VERIFYONLY est utilisée lorsque vous prévoyez de déplacer une base de données sur le même serveur ou de la copier sur un serveur différent, l'option MOVE peut s'avérer nécessaire afin de vérifier que l'espace disponible est nécessaire sur la cible et d'identifier les collisions éventuelles avec des fichiers existants.

  Pour plus d'informations, consultez Copie de bases de données avec la sauvegarde et la restauration.

• PASSWORD = { password | **@**password_variable }

  Remarque :
  Pris en charge par RESTORE, RESTORE FILELISTONLY, RESTORE HEADERONLY et RESTORE VERIFYONLY.

  Fournit le mot de passe du jeu de sauvegarde. Un mot de passe de jeu de sauvegarde est une chaîne de caractères.

  Si un mot de passe a été spécifié lors de la création du jeu de sauvegarde, il est requis lors de chaque opération de restauration à partir du jeu de sauvegarde. La spécification d'un mot de passe incorrect ou d'un mot de passe pour un jeu de sauvegarde qui n'en possède pas constitue une erreur.

  Important :
  Ce mot de passe fournit uniquement une protection faible pour le support de sauvegarde. Pour plus d'informations, consultez la section « Autorisations » pour la rubrique adéquate.

  Remarque :
  L'option PASSWORD sera supprimée dans une future version de SQL Server.

• BLOCKSIZE = { blocksize | **@**blocksize_variable }
  Indique, en octets, la taille maximale de bloc. Les tailles prises en charge sont 512, 1024, 2048, 4096, 8192, 16384, 32768 et 65536 (64 Ko) octets. La valeur par défaut est 65536 pour les périphériques à bandes, 512 sinon. En règle générale, cette option est superflue car RESTORE sélectionne automatiquement une taille de bloc appropriée pour le périphérique. Si vous spécifiez explicitement une taille de bloc, la sélection automatique est annulée et remplacée.

  Si vous restaurez une sauvegarde à partir d'un CD-ROM, spécifiez BLOCKSIZE=2048.

  Remarque :
  En règle générale, cette option n'affecte les performances que si les données sont lues sur des périphériques à bandes.

• BUFFERCOUNT = { buffercount | **@**buffercount_variable }
  Spécifie le nombre total de tampons d'E/S à utiliser pour l'opération de restauration. Vous pouvez spécifier n'importe quel entier positif ; toutefois, un nombre élevé de tampons peut provoquer des erreurs liées à une insuffisance de mémoire. En effet, l'espace d'adressage virtuel peut s'avérer inapproprié dans la tâche Sqlservr.exe.

  L'espace total utilisé par les tampons est déterminé par : buffercount*****maxtransfersize.

• MAXTRANSFERSIZE = { maxtransfersize | **@**maxtransfersize_variable }
  Spécifie, en octets, la plus grande unité de transfert à utiliser entre SQL Server et le support de sauvegarde. Les valeurs possibles sont les multiples de 65536 octets (64 Ko), dans la limite de 4194304 octets (4 Mo).

• ENABLE_BROKER

  Remarque :
  Pris en charge uniquement par RESTORE {DATABASE}.

  Démarre Service Broker en mode activé pour que les messages puissent être envoyés immédiatement. Par défaut, Service Broker démarre en mode désactivé lors d'une restauration.

• ERROR_BROKER_CONVERSATIONS

  Remarque :
  Pris en charge uniquement par RESTORE {DATABASE}.

  Termine toutes les conversations avec une erreur indiquant que la base de données est attachée ou restaurée. Service Broker est désactivé jusqu'à la fin de l'opération, puis il est activé.

• NEW_BROKER

  Remarque :
  Pris en charge uniquement par RESTORE {DATABASE}.

  Crée une nouvelle valeur service_broker_guid dans les bases sys.databases et les bases restaurées, et termine tous les points de terminaison de conversation avec un nettoyage. Service Broker est activé, mais aucun message n'est envoyé aux points de terminaison de conversation distants.

• { RECOVERY | NORECOVERY | STANDBY }

  Remarque :
  Pris en charge uniquement par RESTORE.

  • RECOVERY
    Permet d'imposer, pendant la restauration, l'annulation des transactions non validées. Après la récupération, la base de données est prête à l'emploi. Si aucune des options NORECOVERY, RECOVERY ou STANDBY n'est spécifiée, RECOVERY est choisie par défaut.

    Si d'autres opérations RESTORE (RESTORE LOG ou RESTORE DATABASE) sont planifiées, il faut spécifier NORECOVERY ou STANDBY.

    Lors de la restauration de jeux de sauvegarde à partir d'une version antérieure de SQL Server, il peut s'avérer nécessaire d'opérer une mise à niveau des bases de données. Cette mise à niveau est réalisée automatiquement lorsque WITH RECOVERY est spécifiée. Pour plus d'informations, consultez Application de sauvegardes du journal des transactions.

    Remarque :
    Si la clause FROM est omise, il convient de spécifier NORECOVERY, RECOVERY ou STANDBY dans la clause WITH.

  • NORECOVERY
    Permet d'empêcher, pendant la restauration, l'annulation des transactions non validées. Si un autre journal de transactions a été appliqué ultérieurement, spécifiez l'option NORECOVERY ou STANDBY. Si aucune des options NORECOVERY, RECOVERY ou STANDBY n'est spécifiée, RECOVERY est choisie par défaut. Au cours d'une opération de restauration hors connexion à l'aide de l'option NORECOVERY, la base de données n'est pas utilisable.

    Pour la restauration d'une sauvegarde de base de données et d'un ou de plusieurs journaux de transactions, ou lorsque plusieurs instructions RESTORE sont nécessaires (par exemple en cas de sauvegarde complète d'une base suivie d'une sauvegarde différentielle), RESTORE nécessite l'utilisation de l'option WITH NORECOVERY sur toutes les instructions RESTORE, sauf sur la dernière. Une des méthodes recommandées consiste à utiliser WITH NORECOVERY sur TOUTES les instructions dans une séquence de restauration à plusieurs étapes jusqu'à atteindre le point de récupération souhaité, puis d'utiliser une instruction RESTORE WITH RECOVERY séparée pour la récupération uniquement.

    Employée lors de la restauration d'un fichier ou d'un groupe de fichiers, NORECOVERY oblige la base de données à rester dans l'état de restauration lorsque la restauration est terminée. Cette option est utile dans l'une des situations suivantes :

    • un script de restauration est en cours d'exécution et le journal est toujours appliqué ;
    • une séquence de restaurations de fichiers est exécutée et il n'est pas nécessaire que la base soit utilisable entre les deux opérations de restauration.

    Dans certains cas, RESTORE WITH NORECOVERY restaure la restauration par progression définie à un niveau suffisamment avancé afin d'assurer la cohérence avec la base de données. Dans ces cas, la restauration ne s'effectue pas et les données demeurent hors connexion, comme prévu avec cette option. Le moteur de base de données émet cependant un message d'information qui indique que la restauration par progression définie peut dorénavant être récupérée à l'aide de l'option RECOVERY.

  • STANDBY **=**standby_file_name
    Indique un fichier d'attente qui permet d'annuler les effets de la récupération. L'option STANDBY est autorisée pour la restauration hors connexion (y compris la restauration partielle). L'option est désactivée pour la restauration en ligne. Toute tentative de spécification de l'option STANDBY pour une opération de restauration en ligne entraîne l'échec de l'opération de restauration. STANDBY n'est pas non plus autorisée lorsqu'une mise à niveau de base de données est nécessaire.

    Remarque :
    Dans SQL Server 2000, ce fichier était appelé « fichier d'annulation ».

    Le fichier d'attente sert à conserver une préimage « copie à l'écriture » pour les pages modifiées au cours de la validation de l'annulation de RESTORE WITH STANDBY. Le fichier d'attente permet la constitution d'une base de données accessible en lecture seule entre les restaurations des journaux de transactions ; elle est utilisable avec des serveurs en état de secours semi-automatique ou pour des récupérations spéciales, lorsqu'il s'avère utile d'inspecter la base de données entre les restaurations de journal. Après une opération RESTORE WITH STANDBY, le fichier d'annulation est automatiquement supprimé par l'opération RESTORE suivante. Si ce fichier d'attente est supprimé manuellement avant l'opération RESTORE suivante, alors la totalité de la base de données doit être à nouveau restaurée. Pendant que la base de données se trouve dans un état STANDBY, vous devez traiter ce fichier d'attente avec la même attention que pour n'importe quel autre fichier de base de données. Contrairement aux autres fichiers de base de données, ce fichier est uniquement maintenu ouvert par le moteur de base de données au cours des opérations de restauration actives.

    L'argument standby_file_name spécifie un fichier d'attente dont l'emplacement est stocké dans le journal de la base de données. Si un fichier existant utilise le nom spécifié, le fichier est remplacé ; sinon, le moteur de base de données crée le fichier.

    La taille requise pour un fichier d'attente spécifique dépend du volume d'actions d'annulation issues des transactions non validées au cours de la restauration.

    Important :
    S'il n'y a plus de place sur le disque contenant le fichier d'attente indiqué, la restauration s'arrête.

  Pour comparer RECOVERY et NORECOVERY, consultez la section « Remarques » de la rubrique RESTORE.

• REPLACE

  Remarque :
  Pris en charge uniquement par RESTORE.

  Indique que SQL Server doit créer la base de données spécifiée et ses fichiers même s'il en existe une autre de même nom. En pareil cas, la base existante est supprimée. Lorsque l'option REPLACE n'est pas précisée, une vérification a lieu. Celle-ci évite le remplacement accidentel d'une autre base de données. Cette vérification garantit que l'instruction RESTORE DATABASE ne restaure pas la base de données sur le serveur courant si les deux conditions suivantes existent :

  • la base de données nommée dans l'instruction RESTORE existe déjà sur le serveur en cours, et
  • le nom de la base est différent du nom enregistré dans le jeu de sauvegarde.

  REPLACE permet également à RESTORE de remplacer un fichier existant dont il est impossible de vérifier qu'il appartient à la base de données en cours de restauration. Normalement, RESTORE refuse de remplacer les fichiers existants. WITH REPLACE peut aussi être utilisé de la même manière que l'option RESTORE LOG.

  REPLACE supplante également la nécessité de sauvegarder la fin du journal avant la restauration de la base de données.

  Pour plus d'informations, consultez Utilisation de l'option REPLACE.

• RESTART

  Remarque :
  Pris en charge uniquement par RESTORE.

  Indique que SQL Server doit redémarrer une restauration qui a été interrompue. RESTART relance la restauration au point de son interruption.

• RESTRICTED_USER

  Remarque :
  Pris en charge uniquement par RESTORE.

  Restreint l'accès à la base de données restaurée aux membres des rôles db_owner, dbcreator ou sysadmin. Dans SQL Server 2005, RESTRICTED_USER remplace l'option DBO_ONLY. DBO_ONLY n'est disponible qu'à des fins de compatibilité ascendante.

  Utilisez avec l'option RECOVERY.

  Pour plus d'informations, consultez Définition des options de base de données.

• { REWIND | NOREWIND }
  Ces options ne sont utilisées que dans le cas de périphériques TAPE. S'il ne s'agit pas d'un périphérique à bandes, ces options sont ignorées.

  • REWIND

    Remarque :
    Pris en charge par l'ensemble des six instructions : RESTORE, RESTORE FILELISTONLY, RESTORE HEADERONLY, RESTORE LABELONLY et RESTORE VERIFYONLY.

    Indique que SQL Server libère et rembobine la bande. REWIND est le paramètre par défaut.

  • NOREWIND

    Remarque :
    Pris en charge uniquement par RESTORE et RESTORE VERIFYONLY. La spécification de NOREWIND dans n'importe quel autre argument de restauration génère une erreur.

    Indique que SQL Server maintient la bande ouverte après l'opération de sauvegarde. Cette option vous permet d'améliorer les performances lorsque vous effectuez plusieurs opérations de sauvegarde sur une bande.

    NOREWIND implique NOUNLOAD, et ces options sont incompatibles dans une instruction RESTORE unique.

    Remarque :

    Si vous utilisez NOREWIND, l'instance de SQL Server conserve la propriété du lecteur de bande jusqu'à ce qu'une instruction BACKUP ou RESTORE s'exécutant dans le même processus utilise l'option REWIND ou UNLOAD, ou jusqu'à l'arrêt de l'instance du serveur. Le fait de maintenir la bande ouverte empêche les autres processus d'y accéder. Pour plus d'informations sur l'affichage de la liste des bandes ouvertes et sur leur fermeture, consultez Unités de sauvegarde.

• { UNLOAD | NOUNLOAD }

  Remarque :
  Pris en charge par RESTORE, RESTORE FILELISTONLY, RESTORE HEADERONLY, RESTORE LABELONLY, RESTORE REWINDONLY et RESTORE VERIFYONLY.

  Ces options ne sont utilisées que dans le cas de périphériques TAPE. S'il ne s'agit pas d'un périphérique à bandes, ces options sont ignorées.

  Remarque :
  UNLOAD/NOUNLOAD est un paramètre de session qui reste en vigueur jusqu'à la fin de la session ou tant qu'il n'est pas réinitialisé par le choix de l'option opposée à celle en cours d'utilisation.

  • UNLOAD
    Indique que la bande est automatiquement rembobinée et démontée lorsque la sauvegarde est terminée. UNLOAD est l'option par défaut au démarrage d'une session.
  • NOUNLOAD
    Indique qu'au terme de l'opération RESTORE la bande demeurera chargée dans le lecteur de bande.

• STATS [ = percentage ]

  Remarque :
  Pris en charge par RESTORE et RESTORE VERIFYONLY.

  Affiche un message à chaque fois qu'un autre pourcentage se termine et sert à évaluer l'état d'avancement de l'opération. Si percentage est omis, SQL Server affiche un message à chaque incrément de 10 pour cent (approximativement).

  L'option STATS indique le pourcentage d'achèvement en tant que seuil pour indiquer l'intervalle suivant. Cela se situe approximativement au pourcentage spécifié ; par exemple, avec STATS=10, le moteur de base de données SQL Server 2005 crée un rapport à cet intervalle environ ; par exemple, au lieu d'afficher précisément 40 %, l'option peut afficher 43 %. Pour les jeux de sauvegarde volumineux, cela n'est pas un problème car le pourcentage d'achèvement progresse très lentement entre les appels d'E/S terminés.

• { STOPAT | STOPATMARK | STOPBEFOREMARK }

  Remarque :
  Prise en charge uniquement par l'instruction RESTORE et seulement pour les modes de restauration complète et de récupération utilisant les journaux de transactions.

  • STOPAT = { 'date_time' | **@**date_time_var }
    Indique que la base de données doit être restaurée dans l'état qui était le sien à la date et à l'heure spécifiées.

    Si une variable est employée pour STOPAT, elle doit être du type varchar, char, smalldatetime ou datetime. Seuls les enregistrements de journal écrits avant la date et l'heure spécifiées seront appliqués à la base de données.

    Remarque :
    Si l'heure STOPAT spécifiée est postérieure à la dernière sauvegarde LOG, la base de données reste dans l'état de non restauration, comme si RESTORE LOG avait été exécuté avec NORECOVERY.

    Pour plus d'informations, consultez Restauration d'une base de données vers un point dans une sauvegarde.

  • STOPATMARK = { 'mark_name' | 'lsn:lsn_number' } [ AFTER 'datetime' ]
    Indique une récupération à un point de récupération donné. La transaction spécifiée est incluse dans la récupération, mais elle n'est validée que si elle a été validée à l'origine lors de la véritable génération de la transaction.

    RESTORE DATABASE et RESTORE LOG prennent en charge le paramètre lsn_number. Ce paramètre indique un numéro de séquence de journal.

    Le paramètre mark_name n'est pris en charge que par l'instruction RESTORE LOG. Ce paramètre indique une transaction marquée dans la sauvegarde du journal.

    Dans une instruction RESTORE LOG, si la clause AFTER datetime est omise, la récupération s'arrête à la première marque portant le nom spécifié. Si une valeur est spécifiée pour AFTER datetime, la récupération s'arrête à la première marque portant le nom spécifié, à datetime exactement ou après.

    Remarque :
    Si l'heure, la marque ou le NSE spécifié est postérieur à la dernière sauvegarde LOG, la base de données reste dans l'état de non restauration, comme si RESTORE LOG avait été exécuté avec NORECOVERY.

    Pour plus d'informations, consultez Utilisation des transactions marquées (mode de sauvegarde complète) et Récupération d'un numéro de séquence d'enregistrement (NSE).

  • STOPBEFOREMARK = { 'mark_name' | 'lsn:lsn_number' } [ AFTER 'datetime' ]
    Indique une récupération jusqu'à un point de récupération donné. La transaction spécifiée n'est pas incluse dans la récupération et est restaurée lorsque WITH RECOVERY est utilisé.

    RESTORE DATABASE et RESTORE LOG prennent en charge le paramètre lsn_number. Ce paramètre indique un numéro de séquence de journal.

    Le paramètre mark_name n'est pris en charge que par l'instruction RESTORE LOG. Ce paramètre indique une transaction marquée dans la sauvegarde du journal.

    Dans une instruction RESTORE LOG, si la clause AFTER datetime est omise, la récupération s'arrête juste avant la première marque portant le nom spécifié. Si une valeur est spécifiée pour AFTER datetime, la récupération s'arrête juste avant la première marque portant le nom spécifié, à datetime exactement ou après.

Ensembles de résultats

Pour les ensembles de résultats, consultez les rubriques suivantes :

• RESTORE FILELISTONLY (Transact-SQL)
• RESTORE HEADERONLY (Transact-SQL)
• RESTORE LABELONLY (Transact-SQL)

Notes

Pour des remarques supplémentaires, consultez les rubriques suivantes :

• RESTORE (Transact-SQL)
• RESTORE HEADERONLY (Transact-SQL)
• RESTORE LABELONLY (Transact-SQL)
• RESTORE REWINDONLY (Transact-SQL)
• RESTORE VERIFYONLY (Transact-SQL)

Spécification d'un jeu de sauvegarde

Un jeu de sauvegarde contient la sauvegarde issue d'une opération de sauvegarde unique réussie. Les instructions RESTORE, RESTORE FILELISTONLY, RESTORE HEADERONLY et RESTORE VERIFYONLY fonctionnent sur un jeu de sauvegarde unique dans le jeu de médias sur la ou les unités de sauvegarde spécifiées. Vous devez spécifier la sauvegarde requise à partir du jeu de médias.

L'option permettant de spécifier le jeu de sauvegarde à restaurer est la suivante :

FILE ={ backup_set_file_number | **@**backup_set_file_number }

où backup_set_file_number indique la position de la sauvegarde dans le jeu de médias. Le backup_set_file_number 1 (FILE = 1) désigne le premier jeu de sauvegarde sur le support, le backup_set_file_number 2 (FILE = 2) désigne le deuxième, etc.

Le comportement de cette option varie d'une instruction à l'autre, comme le décrit le tableau suivant.

Instruction

Comportement de l'option FILE du jeu de sauvegarde

RESTORE

Le numéro par défaut du fichier de jeu de sauvegarde est 1. Seule une option FILE de jeu de sauvegarde est autorisée dans une instruction RESTORE. Il est important de spécifier les jeux de sauvegarde dans l'ordre.

RESTORE FILELISTONLY

Le numéro par défaut du fichier de jeu de sauvegarde est 1.

RESTORE HEADERONLY

Par défaut, tous les jeux de sauvegarde du support sont traités. L'ensemble de résultats RESTORE HEADERONLY renvoie des informations sur chaque jeu de sauvegarde, notamment sa position dans le jeu de médias. Pour obtenir des informations sur un jeu de sauvegarde donné, indiquez sa position en guise de valeur backup_set_file_number dans l'option FILE.

Remarque :

Dans le cas d'un support de bande, RESTORE HEADER ne traite que les jeux de sauvegarde figurant sur la bande chargée.

RESTORE VERIFYONLY

La valeur par défaut de backup_set_file_number est 1.

Remarque :
L'option FILE permettant de spécifier un jeu de sauvegarde n'a pas de rapport avec l'option FILE permettant de spécifier un fichier de base de données (FILE = { logical_file_name_in_backup | @logical_file_name_in_backup_var }).

Résumé de prise en charge des options WITH

Les options WITH suivantes sont prises en charge uniquement par l'instruction RESTORE : PARTIAL, KEEP_REPLICATION, { RECOVERY | NORECOVERY | STANDBY }, REPLACE , RESTART , RESTRICTED_USER et { STOPAT | STOPATMARK | STOPBEFOREMARK }

Remarque :
L'option PARTIAL est uniquement prise en charge par RESTORE DATABASE.

Le tableau suivant répertorie les options WITH utilisées par une ou plusieurs instructions et indique quelles instructions prennent en charge quelle option. Une encoche (√) indique qu'une option est prise en charge ; un tiret (— ) signale qu'une option n'est pas prise en charge.

option WITH	RESTORE	RESTORE FILELISTONLY	RESTORE HEADERONLY	RESTORE LABELONLY	RESTORE REWINDONLY	RESTORE VERIFYONLY
{ CHECKSUM | NO_CHECKSUM }	√	√	√	√	—	√
{ CONTINUE_AFTER_ERROR | STOP_ON_ERROR }	√	√	√	√	—	√
FILE1	√	√	√	—	—	√
LOADHISTORY	—	—	—	—	—	√
MEDIANAME	√	√	√	√	—	√
MEDIAPASSWORD	√	√	√	√	—	√
MOVE	√	—	—	—	—	√
PASSWORD	√	√	√	—	—	√
{ REWIND | NOREWIND }	√	REWIND uniquement	REWIND uniquement	REWIND uniquement	—	√
STATS	√	—	—	—	—	√
{ UNLOAD | NOUNLOAD }	√	√	√	√	√	√

1 FILE **=**backup_set_file_number, qui est différent de {FILE | FILEGROUP}.

Autorisations

Pour les autorisations, consultez les rubriques suivantes :

• RESTORE (Transact-SQL)
• RESTORE FILELISTONLY (Transact-SQL)
• RESTORE HEADERONLY (Transact-SQL)
• RESTORE LABELONLY (Transact-SQL)
• RESTORE REWINDONLY (Transact-SQL)
• RESTORE VERIFYONLY (Transact-SQL)

Exemples

Pour les exemples, consultez les rubriques suivantes :

• RESTORE (Transact-SQL)
• RESTORE FILELISTONLY (Transact-SQL)
• RESTORE HEADERONLY (Transact-SQL)

Voir aussi

Référence

BACKUP (Transact-SQL)
RESTORE (Transact-SQL)
RESTORE FILELISTONLY (Transact-SQL)
RESTORE HEADERONLY (Transact-SQL)
RESTORE LABELONLY (Transact-SQL)
RESTORE REWINDONLY (Transact-SQL)
RESTORE VERIFYONLY (Transact-SQL)

Autres ressources

Sauvegarde et restauration de bases de données dans SQL Server

Aide et Informations

Assistance sur SQL Server 2005

Historique des modifications

Version	Historique
12 décembre 2006	Contenu modifié : Ajout de descriptions pour les options BLOCKSIZE, BUFFERCOUNT et MAXTRANSFERSIZE. Correction des descriptions STOPATMARK et STOPBEFOREMARK.
14 avril 2006	Nouveau contenu : Ajout de la section « Spécification d'un jeu de sauvegarde ». Ajout d'une remarque à la description de STOPATMARK. Ajout des sections suivantes qui fournissent des liens vers d'autres rubriques RESTORE contenant des informations utiles : « Syntaxe » « Remarques » « Ensembles de résultats » « Remarques » « Autorisations » « Exemples » Contenu modifié : Révision de la remarque figurant dans la description de STOPAT. Remplacement de la variable logical_file_name par logical_file_name_in_backup. Mise à jour des descriptions des options {REWIND | NOREWIND} et {UNLOAD | NOUNLOAD}.
5 décembre 2005	Nouveau contenu : Ajout des options ENABLE_BROKER et ERROR_BROKER_CONVERSATIONS.