RESTORE Énoncés - Arguments (Transact-SQL)

S'applique à :SQL Server

Cet article documente les arguments décrits dans les sections Syntaxe du RESTORE {DATABASE|LOG} et de l’ensemble associé d’instructions auxiliaires : RESTORERESTORE FILELISTONLY,RESTORE HEADERONLYRESTORE ,RESTORE LABELONLYRESTORE ,RESTORE REWINDONLYRESTORE , et .RESTORERESTORE VERIFYONLY La plupart des arguments sont pris en charge seulement par un sous-ensemble de ces six instructions. Cette prise en charge est précisée dans la description de chacun des arguments.

Conventions de la syntaxe Transact-SQL

Syntaxe

Pour la syntaxe, consultez les articles suivants :

• RESTORE (Transact-SQL)

• RESTORE FILELISTONLY (Transact-SQL)

• RESTORE HEADERONLY (Transact-SQL)

• RESTORE LABELONLY (Transact-SQL)

• RESTORE REWINDONLY (Transact-SQL)

• RESTORE VERIFYONLY (Transact-SQL)

Arguments

DATABASE

Soutenu 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 complète ou utilisant les journaux de transactions, SQL Server nécessite dans la plupart des cas une sauvegarde de la fin du journal, avant la restauration de la base de données. Restaurer une base de données sans d’abord sauvegarder la queue du journal entraîne une erreur, sauf si l’instruction RESTOREDATABASE contient soit la clause WITH REPLACE soit la clause WITH STOPAT, qui doit spécifier un temps ou une transaction ayant eu lieu après la fin de la sauvegarde des données. Pour plus d’informations sur les sauvegardes de la fin du journal, consultez Sauvegardes de la fin du journal (SQL Server).

LOG

Soutenu 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.

Pour plus d’informations, consultez Appliquer les sauvegardes de fichier journal (SQL Server).

{ database_name | @database_name_var }

Soutenu par :RESTORE

Base de données dans laquelle est restaurée la base complète ou le journal des transactions. S’il est 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 de données chaîne de caractères, sauf pour les types de données ntext ou text.

< > file_or_filegroup_or_page [ ,... n ]

Soutenu par :RESTORE

Spécifie le nom d’un fichier, d’un groupe de fichiers ou d’une page logique à inclure dans une RESTOREDATABASE instruction 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 s’il s’agit d’une restauration PARTIAL (qui aboutit à un groupe de fichiers obsolète).

Pour une base de données utilisant le modèle de récupération complet ou en bloc, après avoir restauré RESTOREDATABASE un ou plusieurs fichiers, groupes de fichiers et/ou pages, il faut généralement appliquer le journal de transaction aux fichiers contenant les données restaurées ; appliquer le journal rend ces fichiers cohérents avec le reste de la base de données. Les exceptions sont les suivantes :

• Si les fichiers restaurés étaient en lecture seule avant leur dernière sauvegarde, alors un journal de transactions n’est pas nécessairement appliqué, et la RESTORE déclaration 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.

FICHIER = { 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.

FILE GROUP = { logical_filegroup_name | @logical_filegroup_name_var }

Désigne un groupe de fichiers à inclure dans la restauration de la base de données.

FILEGROUP est autorisé en mode de récupération simple uniquement si le groupe de fichiers spécifié est en lecture seule et s’il s’agit d’une restauration partielle (c’est-à-dire, 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 des pages qui peuvent être restaurées dans un fichier unique au cours d'une séquence de restauration est 1 000. 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 la restauration de pages, consultez Restaurer des pages (SQL Server).

[ , ...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. Alternativement, dans une RESTOREDATABASE instruction, la clause FROM peut spécifier le nom d’un instantané de base de données vers lequel vous revenez à 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.

Soutenu par :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, comme suit :

{ 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. S’il est fourni comme variable (@logical_backup_device_name_var), le nom de l’unité de sauvegarde peut être spécifié sous la forme d’une constante de chaîne (@logical_backup_device_var = logical_backup_device_name) ou d’une variable de type de données chaîne de caractères, sauf pour les types de données ntext ou 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 unités de type disque et bande doivent être spécifiées avec leur nom réel (par exemple, le chemin complet et le nom de fichier) : DISK ='Z:\SQLServerBackups\AdventureWorks.bak' ou TAPE ='\\\\.\TAPE0'. S’il est fourni comme variable (@physical_backup_device_name_var), le nom de l’appareil peut être spécifié sous la forme d’une constante de chaîne (@physical_backup_device_name_var = « physical_backup_device_name ») ou d’une variable de type de données de chaîne de caractères, sauf pour les types de données ntext ou text.

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

Le compte sous lequel vous exécutez SQL Server doit avoir un accès LECTURE à l’ordinateur distant ou au serveur réseau pour effectuer une RESTORE opération.

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

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 ligne permet de restaurer une sauvegarde en utilisant moins d'unités que le nombre nécessaire pour créer la sauvegarde.

• La restauration en ligne nécessite toutes les unités de sauvegarde. Toute tentative avec un nombre d'unités inférieur échoue.

É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.

< >database_snapshot ::=

Soutenu par :RESTORE DATABASE

= DATABASE_SNAPSHOT database_snapshot_name
Rétablit la base de données selon l’instantané de base de données spécifié 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, l'instantané 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é de base de données et la base de données de destination sont tous deux indiqués comme In restore. Pour plus d’informations, consultez la section « Remarques » dans RESTORE DATABASE.

Options WITH

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 cet article.

PARTIAL

Soutenu 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 PARTIELLE n’est pas autorisée sur RESTORE les instructions LOG.

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 l’article Restaurations fragmentaires (SQL Server).

[ RECOVERY | NORECOVERY | VEILLE ]

Soutenu 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 des opérations ultérieures RESTORE (RESTORE LOG, ou RESTOREDATABASE à partir de différentielle) sont prévues, NORECOVERY ou STANDBY doivent être spécifiées à la place.

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 Appliquer les sauvegardes de fichier journal (SQL Server).

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 restaurer une sauvegarde de base de données et un ou plusieurs journaux de transactions, ou chaque fois que plusieurs RESTORE instructions sont nécessaires (par exemple, lors de la restauration d’une sauvegarde complète de la base de données suivie d’une sauvegarde différentielle), RESTORE l’option WITH NORECOVERY est requise sur toutes les instructions sauf la dernière RESTORE . Une bonne pratique consiste à utiliser WITH NORECOVERY sur TOUTES les instructions dans une séquence de restauration en plusieurs étapes jusqu’à atteindre le point de récupération souhaité, puis d’utiliser une instruction WITH RECOVERY séparée RESTORE uniquement pour la récupération.

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 RESTORE cas, AVEC NORECOVERY rolls, le roll forward est suffisamment avancé pour être cohérent 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.

VEILLE = standby_file_name

Indique un fichier journal des annulations 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.

Le fichier de veille est utilisé pour conserver une pré-image « copie-on-write » pour les pages modifiées lors du passage d’annulation d’un RESTORE AVEC STANDBY. Le fichier d'annulation 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 RESTORE opération AVEC STANDBY, le fichier d’annulation est automatiquement supprimé par l’opération suivante RESTORE . Si ce fichier de veille est supprimé manuellement avant la prochaine RESTORE opération, alors toute la base de données doit être restaurée. Pendant que la base de données se trouve dans un état STANDBY, vous devez traiter ce fichier d'annulation 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.

standby_file_name spécifie un fichier d’annulation 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'annulation spécifique dépend du volume d'actions d'annulation issues des transactions non validées au cours de la restauration.

Pour une comparaison de RECOVERY et NON-RECOVERY, voir la section « Remarques » dans RESTORE.

LOADHISTORY

Soutenu par :RESTORE VERIFYONLY

Indique que l’opération de restauration charge les informations dans les tables d’historique msdb. Pour le jeu de sauvegarde unique faisant l’objet d’une vérification, l’option LOADHISTORY charge 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).

N’oubliez pas que l’utilisation de LOADHISTORY pour les sauvegardes qui existent déjà dans les tables d’historique msdb ajoute les mêmes informations avec un nouveau backup_set_id. De plus, si vous utilisez LOADHISTORY pour recréer l’historique de sauvegarde dans msdb, sur un autre serveur ou après sa suppression du serveur d’origine, il est recommandé d’exécuter les commandes de restauration pour les sauvegardes dans l’ordre dans lequel elles ont été prises. Cela garantit que la chaîne LSN reste intacte et que l’Assistant Restauration SSMS lit correctement l’historique de sauvegarde pour générer la séquence de restauration correcte. L’utilisation de LOADHISTORY avec l’historique de sauvegarde recréé dans le désordre peut entraîner une erreur lors de la tentative de restauration (« Impossible de créer un plan de restauration en raison d’une rupture dans la chaîne LSN. (Microsoft.SqlServer.SmoExtended) »).

< > general_WITH_options [ ,... n ]

Les options générales WITH suivantes sont toutes prises en charge dans RESTOREDATABASE les instructions LOG.RESTORE Certaines de ces options sont aussi prises en charge par une ou plusieurs instructions auxiliaires, comme indiqué.

Options de l’opération de restauration

Ces options affectent le comportement de l'opération de restauration.

DÉPLACER 'logical_file_name_in_backup' VERS 'operating_system_file_name' [ ,... n ]

Soutenu 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é en le restaurant à l’emplacement spécifié 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 du jeu de sauvegarde que vous voulez restaurer à un nouvel emplacement. Par défaut, le fichier logical_file_name_in_backup est restauré à son emplacement d’origine.

Si une RESTORE instruction est utilisée pour déplacer une base de données sur le même serveur ou la copier sur un autre serveur, l’option MOVE peut être nécessaire pour déplacer les fichiers de la base de données et éviter les collisions avec les fichiers existants.

Lorsqu’elle est utilisée avec RESTORE LOG, l’option MOVE ne peut être utilisée que pour relocaliser les fichiers ajoutés pendant l’intervalle couvert par la restauration du journal. Par exemple, si la sauvegarde du journal contient une opération d’ajout de fichier pour file23fichier , ce fichier peut être déplacé via l’option DÉPLACER sur RESTORE LOG.

Quand elle est utilisé avec la sauvegarde d’instantané SQL Server, l’option MOVE peut servir uniquement à déplacer des fichiers vers un objet blob Azure dans le même compte de stockage que l’objet blob d’origine. L’option MOVE ne peut pas être utilisée pour restaurer la sauvegarde d’instantané dans un fichier local ou un autre compte de stockage.

Si une RESTORE VERIFYONLY instruction 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 autre serveur, l’option MOVE peut être nécessaire pour vérifier qu’il y a suffisamment d’espace disponible dans la cible et pour identifier les collisions potentielles avec des fichiers existants.

Pour plus d’informations, consultez Copier des bases de données avec la sauvegarde et la restauration.

CREDENTIAL

Soutenu par :RESTORE, RESTORE FILELISTONLY, RESTORE HEADERONLY, RESTORE LABELONLY, et RESTORE VERIFYONLY.

S’applique à : SQL Server 2012 (11.x) SP1 CU2 et versions ultérieures

S’utilise uniquement lors de la restauration d’une sauvegarde à partir de Stockage Blob Microsoft Azure.

REPLACE

Soutenu 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. La vérification de sécurité garantit que l’instruction RESTOREDATABASE ne restaure pas la base de données sur le serveur actuel si les conditions suivantes existent toutes deux :

• La base de données nommée dans l’instruction RESTORE existe déjà sur le serveur actuel, et

• le nom de la base est différent du nom enregistré dans le jeu de sauvegarde.

REPLACE permet RESTORE également d’écraser un fichier existant qui ne peut pas être vérifié comme appartenant à la base de données restaurée. Normalement, RESTORE refuse d’écraser des fichiers préexistants. WITH REPLACE peut aussi être utilisé de la même manière pour 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 sur l’impact de l’utilisation de l’option REMPLACER, voir RESTORE (Transact-SQL).

RESTART

Soutenu 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

Soutenu par :RESTORE.

Limite l’accès de la base de données nouvellement restaurée aux membres des rôles db_owner, dbcreator ou sysadmin. RESTRICTED_USER remplace l'option DBO_ONLY. L’option DBO_ONLY a été supprimée dans SQL Server 2008 (10.0.x).

Utilisez avec l'option RECOVERY.

Options du jeu de sauvegarde

Ces options se rapportent au jeu de sauvegarde qui contient la sauvegarde à restaurer.

FICHIER = { backup_set_file_number | @backup_set_file_number }

Soutenu par :RESTORE, RESTORE FILELISTONLY, RESTORE HEADERONLY, et RESTORE VERIFYONLY.

Identifie le jeu de sauvegarde à restaurer. Ainsi, une valeur numéro_fichier_jeu_sauvegarde égale à 1 indique le premier jeu de sauvegarde sur le support de sauvegarde, et une valeur numéro_fichier_jeu_sauvegarde égale à 2 indique le second jeu. Vous pouvez obtenir la backup_set_file_number d’un ensemble de sauvegarde en utilisant l’instruction RESTORE HEADERONLY .

Lorsque ce n’est pas spécifié, le défaut est 1, sauf dans RESTORE HEADERONLY ce cas tous les ensembles de sauvegarde du jeu de supports sont traités. Pour plus d’informations, consultez Spécification d’un jeu de sauvegarde.

MOT de passe = { mot de passe | @password_variable }

Soutenu 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.

[ METADATA_ONLY | INSTANTANÉ ] [ DBNAME = { <database_name> | @database_name_variable } ]

Introduite dans SQL Server 2022 (16.x).

Obligatoire pour la restauration à partir d’une sauvegarde d’instantané. BACKUP SERVER ou BACKUP GROUP... Consultez Créer une sauvegarde d’instantané Transact-SQL.

METADATA_ONLY est synonyme de SNAPSHOT. VDI (Virtual Device Interface) utilise SNAPSHOT. Pour plus d’informations, consultez les informations de référence sur VDI (Virtual Device Interface).

Options du support de sauvegarde

Ces options s'appliquent à l'ensemble du support de sauvegarde.

MEDIANAME = { media_name | @media_name_variable }

Soutenu 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. Si aucun nom de média n’est indiqué dans l’instruction RESTORE , la vérification d’un nom de média correspondant sur les volumes de sauvegarde n’est pas effectuée.

MEDIAPASSWORD = { mediapassword | @mediapassword_variable }

Soutenu 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.

TAILLE DE BLOC = { taille | de bloc@blocksize_variable }

Soutenu par :RESTORE

Indique, en octets, la taille physique du 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 n’est pas nécessaire, car RESTORE sélectionne automatiquement une taille de bloc appropriée à l’appareil. 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.

Options de transfert de données

Ces options vous permettent d'optimiser le transfert de données à partir de l'unité de sauvegarde.

BUFFERCOUNT = { buffercount | @buffercount_variable }

Soutenu par :RESTORE

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 mémoires tampons est déterminé par : buffercount****maxtransfersize.

MAXTRANSFERSIZE = { maxtransfersize | @maxtransfersize_variable }

Soutenu par :RESTORE

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).

Options de gestion des erreurs

Ces options vous permettent de déterminer si les sommes de contrôle de sauvegarde sont activées pour l’opération de restauration et si l’opération doit s’arrêter en présence d’une erreur.

{ SOMME DE CONTRÔLE | NO_CHECKSUM }

Soutenu 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, lorsqu’une somme de contrôle invalide est RESTORE signalée par une erreur de somme de contrôle et s’arrête. Cependant, si vous spécifiez CONTINUE_AFTER_ERROR, RESTORE cela procéde après avoir renvoyé une erreur de somme de contrôle et le numéro de la page contenant la somme de contrôle invalide, si la corruption le permet.

Pour plus d’informations sur l’utilisation de sommes de contrôle de sauvegarde, consultez Erreurs de support possibles pendant les opérations de sauvegarde et de restauration (SQL Server).

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

{ STOP_ON_ERROR | CONTINUE_AFTER_ERROR }

Soutenu 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. C’est le comportement par défaut pour RESTORE, sauf pour VERIFYONLY, qui a CONTINUE_AFTER_ERROR comme défaut.

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

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 ces erreurs (par exemple une sauvegarde effectuée avant que les pages aient été 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 essayer de sauver les données.

Options FILESTREAM

FILESTREAM ( DIRECTORY_NAME =directory_name )

Soutenu par :RESTORE et RESTORE VERIFYONLY

S’applique à : SQL Server 2012 (11.x) et ultérieur

Nom de répertoire compatible avec Windows. Ce nom doit être unique parmi tous les noms de répertoire FILESTREAM au niveau de la base de données dans cette instance SQL Server. La comparaison d'unicité s'effectue sans respect de la casse, quels que soient les paramètres de classement SQL Server.

Options de surveillance

Ces options vous permettent de surveiller le transfert des données à partir de l'unité de sauvegarde.

STATS [ = pourcentage ]

Soutenu 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 (environ).

L'option STATS signale le pourcentage terminé comme seuil de rapport de l'intervalle suivant. Cela se situe approximativement au pourcentage spécifié ; par exemple, avec STATS=10, le Moteur de base de données crée un rapport à cet intervalle environ ; ainsi, 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.

Options des périphériques à bandes

Ces options sont utilisées uniquement pour les périphériques À BANDES. S'il ne s'agit pas d'un périphérique à bandes, ces options sont ignorées.

{ REMBOBINER | NOREWIND }

Ces options sont utilisées uniquement pour les périphériques À BANDES. Si vous n'utilisez pas un périphérique à bandes, ces options sont ignorées.

REWIND
Soutenu par :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
Soutenu 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 quand vous effectuez plusieurs opérations de sauvegarde sur une bande.

NOREWIND implique NONLOAD, et ces options sont incompatibles dans une seule RESTORE affirmation.

{ DÉCHARGER | NONLOAD }

Soutenu par :RESTORE, RESTORE FILELISTONLY, RESTORE HEADERONLY, RESTORE LABELONLY, RESTORE REWINDONLY, et RESTORE VERIFYONLY.

Ces options sont utilisées uniquement pour les périphériques À BANDES. Si vous n'utilisez pas un périphérique à bandes, ces options sont ignorées.

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
Spécifie qu’après l’opération, la RESTORE bande reste chargée sur le lecteur de bande.

<replication_WITH_option>

Cette option est utile seulement si la base de données a été répliquée lors de la création de la sauvegarde.

KEEP_REPLICATION
Soutenu par :RESTORE

Utilisez KEEP_REPLICATION quand vous couplez la réplication à la copie des journaux de transaction. 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 du serveur en état de secours actif doivent être synchronisées avec les bases de données msdb et master du serveur principal.

• Le serveur en état de secours semi-automatique doit être renommé pour utiliser le même nom que le serveur primaire.

<change_data_capture_WITH_option>

Cette option est utile seulement si la base de données a été activée pour la capture de données modifiées, lors de la création de la sauvegarde.

KEEP_CDC

Soutenu par :RESTORE

KEEP_CDC permet d’empêcher la suppression des paramètres de capture de données modifiées quand une sauvegarde de base de données ou de fichier journal est restaurée sur un autre serveur 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.

La restauration de la base de données avec KEEP_CDC ne crée pas les travaux de capture de données modifiées. Pour extraire les modifications du journal après avoir restauré la base de données, recréez le travail de capture et le travail de nettoyage pour la base de données restaurée. Pour plus d’informations, consultez sys.sp_cdc_add_job (Transact-SQL).

Pour plus d’informations sur l’utilisation de la capture de données modifiées avec la mise en miroir de bases de données, consultez Capture de données modifiées et autres fonctionnalités de SQL Server.

<service_broker_WITH_options>

Active ou désactive la remise de messages Service Broker ou définit un nouvel identificateur Service Broker. Cette option est utile seulement si Service Broker a été activé pour la base de données lors de la création de la sauvegarde.

{ ENABLE_BROKER | ERROR_BROKER_CONVERSATIONS | NEW_BROKER }

Soutenu par :RESTORE DATABASE

ENABLE_BROKER
Indique que la remise de messages Service Broker est activée à la fin de la restauration, ce qui permet l’envoi immédiat de messages. Par défaut, la remise de messages Service Broker est désactivée pendant une restauration. La base de données conserve l'identificateur Service Broker existant.

ERROR_BROKER_CONVERSATIONS
Termine toutes les conversations avec une erreur indiquant que la base de données est attachée ou restaurée. De cette façon, vos applications peuvent effectuer un nettoyage standard des conversations existantes. La remise des messages Service Broker est désactivée jusqu'à la fin de l'opération, puis est réactivée. La base de données conserve l'identificateur Service Broker existant.

NEW_BROKER
Spécifie qu'un nouvel identificateur Service Broker doit être assigné à la base de données. Dans la mesure où la base de données est considérée comme un nouveau Service Broker, toutes les conversations existantes dans la base de données sont immédiatement supprimées sans générer de message de fin de dialogue. Tout itinéraire faisant référence à l'ancien identificateur Service Broker doit être recréé avec le nouvel identificateur.

<point_in_time_WITH_options>

Soutenu par :RESTORE {DATABASE|LOG} et uniquement pour les modèles de récupération complets ou en masse.

Vous pouvez restaurer une base de donnés à un point dans le temps ou une transaction spécifique en spécifiant le point de récupération cible dans une clause STOPAT, STOPATMARK ou STOPBEFOREMARK. Un point dans le temps ou une transaction spécifié(e) est toujours restauré(e) à partir d'une sauvegarde du journal. Dans chaque RESTORE instruction LOG de la séquence de restauration, vous devez spécifier votre temps cible ou votre transaction dans une clause identique STOPAT, STOPATMARK ou STOPBEFOREMARK.

En guise de condition préalable à une restauration limitée dans le temps, vous devez tout d'abord restaurer une sauvegarde de base de données complète dont le point de terminaison est antérieur à votre point de récupération cible. Pour vous aider à identifier quelle sauvegarde de base de données restaurer, vous pouvez éventuellement spécifier votre clause WITH STOPAT, STOPATMARK ou STOPBEFOREMARK dans une RESTOREDATABASE instruction pour générer une erreur si une sauvegarde de données est trop récente pour le temps cible spécifié. Cependant, la sauvegarde de données complète est toujours restaurée, même si elle contient le point dans le temps cible.

{ STOPAT | STOPATMARK | STOPBEFOREMARK }

STOPAT = { 'datetime' | @_datetime_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 par le paramètre datetime ou @datetime_var. Pour plus d’informations sur la définition d’une date et d’une heure, consultez Types de données et fonctions de date et d’heure (Transact-SQL).

Si une variable est utilisée pour STOPAT, elle doit être de 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.

Pour plus d’informations, consultez Restaurer une base de données SQL Server jusqu’à une limite dans le temps (mode de récupération complète).

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.

Et LOG supportent tous deux RESTOREDATABASE le paramètre lsn_number.RESTORE Ce paramètre spécifie un numéro séquentiel dans le journal.

Le paramètre mark_name n’est pris en charge que par l’instruction RESTORE LOG. Ce paramètre identifie une marque de transaction dans la sauvegarde du fichier journal.

Dans une RESTORE instruction LOG, si APRÈS la date-heure est omise, la récupération s’arrête au premier repère 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é, exactement à datetime ou après.

Pour plus d’informations, consultez Utiliser les transactions marquées pour récupérer des bases de données associées uniformément (mode de récupération complète) et Récupérer un numéro séquentiel dans le journal (SQL Server).

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

Et LOG supportent tous deux RESTOREDATABASE le paramètre lsn_number.RESTORE Ce paramètre spécifie un numéro séquentiel dans le journal.

Le paramètre mark_name n’est pris en charge que par l’instruction RESTORE LOG. Ce paramètre identifie une marque de transaction dans la sauvegarde du fichier journal.

Dans une RESTORE instruction LOG, si APRÈS la date-heure 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é, exactement à datetime ou après.

Jeux de résultats

Pour les jeux de résultats, consultez les articles suivants :

• RESTORE FILELISTONLY (Transact-SQL)

• RESTORE HEADERONLY (Transact-SQL)

• RESTORE LABELONLY (Transact-SQL)

Notes

Pour des remarques supplémentaires, consultez les articles suivants :

• 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 réussie unique. RESTORE, RESTORERESTORE FILELISTONLY, RESTORERESTORE HEADERONLY, et RESTORERESTORE VERIFYONLY les instructions fonctionnent sur un seul ensemble de sauvegarde au sein de l’ensemble média sur le ou les périphériques de sauvegarde spécifiés. Vous devez spécifier la sauvegarde requise à partir du jeu de médias. Vous pouvez obtenir la backup_set_file_number d’un ensemble de sauvegarde en utilisant l’instruction RESTORE HEADERONLY .

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

FILE ={ backup_set_file_number backup_set_file_number | @ }

backup_set_file_number indique la position de la sauvegarde dans le support de sauvegarde. Quand backup_set_file_number a la valeur 1 (FILE = 1), il s’agit du premier jeu de sauvegarde sur le support de sauvegarde ; quand backup_set_file_number a la valeur 2 (FILE = 2), il s’agit du deuxième jeu de sauvegarde, et ainsi de suite.

Le comportement de cette option varie en fonction de l’instruction, comme l’indique le tableau suivant :

Résumé de prise en charge des options WITH

Les options WITH suivantes sont prises en charge uniquement par l’instruction RESTORE : BLOCKSIZE, BUFFERCOUNT, MAXTRANSFERSIZE, PARTIAL, KEEP_REPLICATION, { RECOVERY | AUCUNE RÉCUPÉRATION | ATTENDEZ }, REMPLACEZ, REDÉMARREZ, RESTRICTED_USER, et { STOPAT | STOPATMARK | STOPBEFOREMARK }

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 coche (√) indique qu’une option est prise en charge ; un tiret (-) indique qu’une option n’est pas prise en charge.

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

Autorisations

Pour les autorisations, consultez les articles suivants :

• 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 obtenir des exemples, consultez les articles suivants :

• RESTORE (Transact-SQL)

• RESTORE FILELISTONLY (Transact-SQL)

• RESTORE HEADERONLY (Transact-SQL)

Étapes suivantes

• 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)
• Sauvegarder et restaurer des bases de données SQL Server
• FILESTREAM (SQL Server)