Поделиться через

RESTORE (Transact-SQL)

  • Статья

Восстанавливает резервные копии, выполненные при помощи команды BACKUP. Эта команда позволяет выполнить следующие сценарии восстановления.

  • Восстановить базу данных из полной резервной копии (полное восстановление).

  • Восстановить часть базы данных (частичное восстановление).

  • Восстановить в базе данных определенные файлы или файловые группы (восстановление файлов).

  • Восстановить в базе данных определенные страницы (восстановление страниц).

  • Восстановить в базе данных журнал транзакций (восстановление журнала транзакций).

  • Вернуть базу данных к моменту времени, на который был выполнен моментальный снимок базы данных.

Дополнительные сведения о сценариях восстановления SQL Server см. в разделе Обзор процессов восстановления (SQL Server). Дополнительные сведения об описаниях аргументов см. в разделе Аргументы инструкции RESTORE (Transact-SQL).

Примечание

Дополнительные сведения о восстановлении из службы хранилища больших двоичных объектов Windows Azure см. в разделе Резервное копирование и восстановление SQL Server с помощью службы хранилищ больших двоичных объектов Windows Azure.

Применимо для следующих объектов: SQL Server (начиная с SQL Server 2008 до текущей версии).

Значок ссылки на раздел Синтаксические обозначения в Transact-SQL

Синтаксис

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

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

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

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

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

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

<backup_device>::=
{ 
   { logical_backup_device_name |
      @logical_backup_device_name_var }
 | { DISK | TAPE | URL } = { 'physical_backup_device_name' |
      @physical_backup_device_name_var } 
} 
Note: URL is the format used to specify the location and the file name for the Windows Azure Blob. Although Windows Azure storage is a service, the implementation is similar to disk and tape to allow for a consistent and seemless restore experince for all the three devices. 
<files_or_filegroups>::= 
{ 
   FILE = { logical_file_name_in_backup | @logical_file_name_in_backup_var } 
 | FILEGROUP = { logical_filegroup_name | @logical_filegroup_name_var } 
 | READ_WRITE_FILEGROUPS
} 

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

--Backup Set Options
 | FILE = { backup_set_file_number | @backup_set_file_number } 
 | PASSWORD = { password | @password_variable } 

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

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

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

--Monitoring Options
 | STATS [ = percentage ] 

--Tape Options
 | { REWIND | NOREWIND } 
 | { UNLOAD | NOUNLOAD } 
  
<replication_WITH_option>::=
 | KEEP_REPLICATION 

<change_data_capture_WITH_option>::=
 | KEEP_CDC

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


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


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

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

Аргументы

Описания аргументов см. в разделе Аргументы инструкции RESTORE (Transact-SQL).

Сведения о сценариях восстановления

SQL Server поддерживает различные сценарии восстановления.

Дополнительные сведения о параметрах инструкции RESTORE

Неподдерживаемые ключевые слова инструкции RESTORE

В SQL Server 2008 следующие ключевые слова больше не поддерживаются.

Неподдерживаемое ключевое слово

Заменены на...

Пример заменяющего ключевого слова

LOAD

RESTORE

RESTORE DATABASE

TRANSACTION

LOG

RESTORE LOG

DBO_ONLY

RESTRICTED_USER

RESTORE DATABASE ... WITH RESTRICTED_USER

RESTORE LOG

Инструкция RESTORE LOG может включать список файлов, создаваемых во время наката. Эта возможность используется, если резервная копия журналов содержит журнальные записи, произведенные во время добавления файла в базу данных.

Примечание

Для базы данных, использующей модель полного восстановления или модель восстановления с неполным протоколированием, необходимо, чтобы перед восстановлением базы данных была создана резервная копия конца журнала.Восстановление базы данных без создания резервной копии заключительного фрагмента журнала приведет к ошибке, если инструкция RESTORE DATABASE не содержит предложение WITH REPLACE или WITH STOPAT, в котором должно указываться время или транзакция, выполняемая после завершения резервного копирования данных.Дополнительные сведения о резервных копиях заключительного фрагмента журнала см. в разделе Резервные копии заключительного фрагмента журнала (SQL Server).

Сравнение параметров RECOVERY и NORECOVERY

Откат контролируется инструкцией RESTORE при помощи параметров [ RECOVERY | NORECOVERY ].

  • Параметр NORECOVERY указывает на то, что откат не производится. Это позволяет продолжать накат при помощи следующей инструкции в последовательности.

    В этом случае последовательность восстановления может восстановить другие резервные копии и выполнить их накат.

  • Параметр RECOVERY (параметр по умолчанию) указывает на то, что откат должен быть выполнен после завершения наката для текущей резервной копии.

    Для восстановления базы данных необходимо, чтобы весь набор восстанавливаемых данных (набор данных наката) был согласован с базой данных. Если набор данных наката, необходимый для согласования с базой данных, достаточно велик и указан параметр RECOVERY, компонент Компонент Database Engine формирует ошибку.

Поддержка совместимости

Резервные копии баз данных master, model и msdb, созданных в более ранней версии SQL Server, восстановить на SQL Server 2014 невозможно.

Примечание

Резервная копия SQL Server не может быть восстановлена на SQL Server, имеющем более раннюю версию.

В каждой версии SQL Server используется путь по умолчанию, отличный от пути в предыдущих версиях. Поэтому, чтобы восстановить из резервной копии базу данных, созданную в расположении по умолчанию для архивов предыдущих версий, необходимо использовать параметр MOVE. Сведения о новом пути по умолчанию см. в разделе Расположение файлов для экземпляра по умолчанию и именованных экземпляров SQL Server.

Если восстановить базу данных предыдущей версии до SQL Server 2014, то эта база данных автоматически обновится. Как правило, база данных сразу становится доступной. Однако если база данных SQL Server 2005 содержит полнотекстовые индексы, то в процессе обновления будет произведен их импорт, сброс или перестроение, в зависимости от установленного значения свойства сервера upgrade_option. Если при обновлении выбран импорт (upgrade_option = 2) или перестроение (upgrade_option = 0), то полнотекстовые индексы во время обновления будут недоступны. В зависимости от объема индексируемых данных процесс импорта может занять несколько часов, а перестроение — в несколько (до десяти) раз больше. Обратите внимание, что если для обновления выбран режим «Импортировать», а полнотекстовый каталог недоступен, то связанные с ним полнотекстовые индексы будут перестроены. Чтобы изменить значение свойства сервера upgrade_option, следует использовать процедуру sp_fulltext_service.

При первом присоединении базы данных к новому экземпляру SQL Server или ее восстановлении копия главного ключа базы данных (зашифрованная главным ключом службы) еще не хранится на сервере. Необходимо расшифровать главный ключ базы данных с помощью инструкции OPEN MASTER KEY. Как только главный ключ базы данных будет расшифрован, появится возможность разрешить автоматическую расшифровку в будущем с помощью инструкции ALTER MASTER KEY REGENERATE, чтобы оставить на сервере копию главного ключа базы данных, зашифрованного с помощью главного ключа службы. После обновления базы данных с переходом от более ранней версии главный ключ базы данных должен быть создан повторно для использования нового алгоритма шифрования AES. Дополнительные сведения о повторном создании главного ключа базы данных см. в разделе ALTER MASTER KEY (Transact-SQL). Время, необходимое для повторного создания главного ключа базы данных с обновлением до алгоритма шифрования AES, зависит от числа объектов, защищаемых главным ключом базы данных. Повторное создание главного ключа базы данных с обновлением до алгоритма шифрования AES необходимо произвести только один раз. Это никак не повлияет на последующие операции повторного создания, выполняемые в соответствии со стратегией смены ключей.

Общие замечания

Во время автономного восстановления, если указанная база данных используется, функция RESTORE после короткой задержки принудительно отключает пользователей. Для восстановления в режиме «в сети» непервичной файловой группы база данных может продолжать использоваться, за исключением тех случаев, когда восстанавливаемая файловая группа переводится в режим вне сети. Данные в указанной базе данных заменяются восстановленными данными.

Дополнительные сведения о восстановлении базы данных см. в разделе Обзор процессов восстановления (SQL Server).

Операции восстановления между несколькими платформами, даже между процессорами различных типов, могут выполняться, если параметры сортировки базы данных поддерживаются операционной системой.

После возникновения ошибки инструкция RESTORE может быть запущена вновь. Кроме того, можно указать, чтобы, несмотря на ошибки, инструкция RESTORE продолжала работу и восстановила как можно большее количество данных (см. параметр CONTINUE_AFTER_ERROR).

Инструкция RESTORE недопустима в явной или неявной транзакции.

Восстановление поврежденной базы данных master выполняется при помощи специальной процедуры. Дополнительные сведения см. в разделе Резервное копирование и восстановление системных баз данных (SQL Server).

Восстановление базы данных из копии удаляет кэш планов для экземпляра SQL Server. Очистка кэша планов становится причиной перекомпиляции всех последующих планов выполнения и приводит к непредвиденному временному снижению производительности обработки запросов. Для каждого удаленного хранилища кэша в кэше планов журнал ошибок SQL Server содержит следующее информационное сообщение: «SQL Server обнаружил %d экземпляров, записанных на диск хранилищ кэша для хранилища кэша "%s" (части кэша планов) в результате операций по обслуживанию или изменению настройки базы данных». Это сообщение добавляется в журнал каждые пять минут при сбросе кэша в течение этого интервала времени.

Чтобы восстановить базу данных доступности, сначала восстановите базу данных в экземпляре SQL Server, а затем добавьте базу данных в группу доступности.

Совместимость

Настройка базы данных и восстановление

Во время восстановления большинство параметров базы данных, устанавливаемых при помощи инструкции ALTER DATABASE, сбрасывается в значения, в которых они находились в конце резервного копирования.

Однако использование параметра WITH RESTRICTED_USER переопределяет этот режим работы для настройки параметра доступа пользователя. Эта настройка всегда сохраняется, если инструкция RESTORE включает параметр WITH RESTRICTED_USER.

Восстановление зашифрованной базы данных

Чтобы восстановить зашифрованную базу данных, необходимо иметь доступ к сертификату или асимметричному ключу, который использовался для шифрования базы данных. Без сертификата или асимметричного ключа восстановить базу данных нельзя. Поэтому сертификат, используемый для шифрования ключа шифрования базы данных, необходимо хранить до тех пор, пока будет нужна резервная копия. Дополнительные сведения см. в разделе Сертификаты SQL Server и асимметричные ключи.

Восстановление базы данных с включенным форматом хранения vardecimal

Резервное копирование и восстановление правильно работают с форматом хранения vardecimal. Дополнительные сведения о формате хранения vardecimal см. в разделе sp_db_vardecimal_storage_format (Transact-SQL).

Восстановление полнотекстовых данных

Во время полного восстановления полнотекстовые данные восстанавливаются вместе с другими данными базы данных. С помощью обычного синтаксиса RESTORE DATABASE database_name FROM backup_device полнотекстовые файлы восстанавливаются как часть файлов базы данных.

Инструкция RESTORE может также использоваться для восстановления в разные расположения, для разностного восстановления, восстановления файлов и файловых групп, а также для восстановления файлов и файловых групп полнотекстовых данных. Кроме того, инструкция RESTORE может восстанавливать как полнотекстовые файлы, так и файлы с данными базы данных.

Примечание

Полнотекстовые каталоги, импортированные из SQL Server 2005, по-прежнему рассматриваются как файлы базы данных.Для них остается применимой процедура SQL Server 2005 по резервному копированию полнотекстовых каталогов, за исключением того, что более нет необходимости использовать паузу и возобновление в процессе выполнения резервного копирования.Дополнительные сведения см. в разделе Резервное копирование и восстановление полнотекстовых каталогов.

Метаданные

SQL Server включает таблицы журналов резервного копирования и восстановления, в которые заносятся данные слежения за резервным копированием и восстановлением для каждого экземпляра сервера. При выполнении восстановления таблицы журнала резервного копирования также изменяются. Сведения об этих таблицах см. в разделе Журнал и сведения о заголовке резервной копии (SQL Server).

Влияние параметра REPLACE

Параметр REPLACE должен использоваться редко и после тщательного анализа. Восстановление обычно не допускает случайной перезаписи базы данных другой базой данных. Если указанная в инструкции RESTORE база данных уже существует на текущем сервере, а идентификатор GUID семейства для заданной базы данных отличается от идентификатора GUID семейства для базы данных, записанного в резервном наборе данных, то ее восстановление не будет выполнено. Это является важной защитной мерой.

Параметр REPLACE отменяет несколько важных проверок, обычно выполняемых операцией восстановления. Отменяются следующие проверки.

  • Проверка на восстановление поверх существующей базы данных резервной копии, созданной для другой базы данных.

    При использовании параметра REPLACE при восстановлении можно записать данные поверх существующей базы данных независимо от того, какие базы данных содержатся в резервном наборе данных, даже если указанное имя данных отличается от записанного в резервном наборе. Это может привести к случайной перезаписи поверх базы данных другой базы данных.

  • Проверка на восстановление базы данных, использующей модель полного восстановления или модель восстановления с неполным протоколированием, для которой не была создана резервная копия заключительного фрагмента журнала, и не был применен параметр STOPAT.

    При использовании параметра REPLACE возможна потеря зафиксированных данных, поскольку последние записанные в журнал данные еще не были скопированы в резервную копию.

  • Перезапись существующих файлов.

    Проверка на перезапись существующих файлов неверного типа (например XLS-файлов) или файлов, используемых другой базой данных, в данный момент находящейся не в режиме в сети. Возможна случайная потеря данных в случае перезаписи существующих файлов, несмотря на то, что восстановленная база данных будет полной.

Повторное восстановление

Отменить результаты восстановления невозможно, однако можно отменить результаты копирования данных и произвести накат для каждого файла по отдельности. Для перезапуска восстановите нужный файл и выполните накат повторно. Например, если случайно было восстановлено слишком много резервных копий журналов и нужная точка остановки восстановления пройдена, нужно перезапустить последовательность.

Последовательность восстановления может быть прервана и перезапущена при восстановлении всего содержимого соответствующих файлов.

Восстановление базы данных к моментальному снимку базы данных

Операция восстановления базы данных, указываемая с помощью параметра DATABASE_SNAPSHOT, переносит всю базу данных-источник назад во времени, восстанавливая ее на момент создания моментального снимка базы данных, т.е. перезаписывая базу данных-источник данными из указанного моментального снимка. В данный момент может существовать только моментальный снимок, к которому выполняется восстановление. Затем операция отката вновь создает журнал (поэтому впоследствии нельзя будет выполнить накат возвращенной базы данных к точке пользовательской ошибки).

Потеря данных затронет только изменения в базе данных, произведенные после создания моментального снимка. Метаданные возвращенной базы данных соответствуют метаданным времени создания моментального снимка. Однако при возвращении к моментальному снимку удаляются все полнотекстовые каталоги.

Возврат из моментальных снимков базы данных не предназначен для восстановления носителей. В отличие от обычного резервного набора данных, моментальный снимок базы данных является неполной копией файлов базы данных. В том случае, если база данных или моментальный снимок базы данных повреждены, возврат из моментального снимка может оказаться невозможным. Более того, даже если оно окажется возможным, восстановление в случае повреждения вряд ли поможет устранить проблему.

Ограничения на возврат

Возврат не поддерживается в следующих условиях.

  • Если база данных-источник содержит файловые группы, доступные только для чтения, или сжатые файловые группы.

  • Если какие-либо файлы, работавшие в режиме «вне сети» во время создания моментального снимка, сейчас работают автономно.

  • Если в настоящий момент существует несколько моментальных снимков базы данных.

Дополнительные сведения см. в разделе Восстановление базы данных до состояния, сохраненного в моментальном снимке.

Безопасность

В операции создания резервной копии могут дополнительно указываться пароли для набора носителей, резервного набора данных или и того и другого. Если для набора носителей или резервного набора данных установлен пароль, то в инструкции RESTORE необходимо указывать правильные пароли. Эти пароли предотвращают несанкционированные операции восстановления и присоединения резервных наборов данных к носителю при помощи инструментальных средств SQL Server. Однако защищенный паролем носитель может быть переписан инструкцией BACKUP с параметром FORMAT.

Примечание по безопасностиПримечание по безопасности

Данный пароль не обеспечивает надежную защиту.Он предназначен для предотвращения неверного восстановления при использовании средств SQL Server авторизованными или неавторизованными пользователями.При этом остается возможным чтение данных резервных копий с помощью других средств или замена пароля.В будущей версии Microsoft SQL Server этот компонент будет удален. Избегайте использования этого компонента в новых разработках и запланируйте изменение существующих приложений, в которых он применяется. Рекомендуемым способом защиты резервных копий является хранение лент с резервными копиями в безопасном месте или создание резервных копий на диске в виде файлов, защищенных соответствующими списками управления доступом (ACL).Списки ACL должны располагаться в корневом каталоге, в котором создаются резервные копии.

Сведения, связанные с резервным копированием и восстановлением SQL Server с использованием хранилища BLOB-объектов Windows Azure, см. в разделе Резервное копирование и восстановление SQL Server с помощью службы хранилищ больших двоичных объектов Windows Azure.

Разрешения

Если восстанавливаемая база данных не существует, для выполнения инструкции RESTORE у пользователя должны быть разрешения CREATE DATABASE. Если база данных существует, разрешения на выполнение инструкции RESTORE по умолчанию предоставлены членам предопределенных ролей сервера sysadmin и dbcreator, а также владельцу базы данных (dbo) (для параметра FROM DATABASE_SNAPSHOT база данных всегда существует).

Разрешения на выполнение инструкции RESTORE даются ролям, в которых данные о членстве всегда доступны серверу. Так как членство в предопределенной роли базы данных может быть проверено, только если эта база данных доступна и не повреждена, что не всегда имеет место при выполнении инструкции RESTORE, члены предопределенной роли базы данных db_owner не имеют разрешений RESTORE.

Примеры

Во всех примерах предполагается, что выполнено полное резервное копирование базы данных.

Примеры выполнения инструкции RESTORE.

  • А. Восстановление всей базы данных

  • Б. Восстановление полной и разностной резервных копий базы данных

  • В. Восстановление базы данных с использованием синтаксиса RESTART

  • Г. Восстановление базы данных и перемещение файлов

  • Д. Копирование базы данных с помощью BACKUP и RESTORE

  • Е. Восстановление состояния на определенный момент времени с помощью STOPAT

  • Ж. Восстановление журнала транзакций до метки

  • З. Восстановление с использованием синтаксиса TAPE

  • И. Восстановление с использованием синтаксиса FILE и FILEGROUP

  • К. Возврат из моментального снимка базы данных

  • Л. Восстановление из службы хранилища BLOB-объектов Windows Azure Примеры

Примечание

Дополнительные примеры см. в разделах руководства по восстановлению, перечисленных в разделе Обзор процессов восстановления (SQL Server).

А.Восстановление всей базы данных

В следующем примере производится восстановление базы данных из полной резервной копии, находящейся на логическом устройстве резервного копирования на магнитной ленте AdventureWorksBackups. Пример создания этого устройства см. в разделе Устройства резервного копирования.

RESTORE DATABASE AdventureWorks2012 
   FROM AdventureWorks2012Backups;

Примечание

Для базы данных, использующей модель полного восстановления или модель восстановления с неполным протоколированием, SQL Server в большинстве случаев требует, чтобы перед восстановлением базы данных была создана резервная копия конца журнала.Дополнительные сведения см. в разделе Резервные копии заключительного фрагмента журнала (SQL Server).

[В начало списка примеров]

Б.Восстановление полной и разностной резервных копий базы данных

В данном примере производится восстановление полной резервной копии базы данных, за которым следует восстановление из разностной резервной копии с устройства резервного копирования Z:\SQLServerBackups\AdventureWorks2012.bak, на котором содержатся обе резервные копии. Полная резервная копия базы данных — это шестой резервный набор данных на устройстве (FILE = 6), а разностная резервная копия базы данных — девятый резервный набор данных на устройстве (FILE = 9). База данных будет восстановлена после восстановления разностной резервной копии.

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

[В начало списка примеров]

В.Восстановление базы данных с использованием синтаксиса RESTART

В данном примере параметр RESTART используется для перезапуска операции RESTORE, прерванной ошибкой питания на сервере.

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

[В начало списка примеров]

Г.Восстановление базы данных и перемещение файлов

В следующем примере производится полное восстановление базы данных и журнала транзакций, после чего восстановленная база данных перемещается в каталог C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\Data.

RESTORE DATABASE AdventureWorks2012
   FROM AdventureWorksBackups
   WITH NORECOVERY, 
      MOVE 'AdventureWorks2012_Data' TO 
'C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\Data\NewAdvWorks.mdf', 
      MOVE 'AdventureWorks2012_Log' 
TO 'C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\Data\NewAdvWorks.ldf';
RESTORE LOG AdventureWorks2012
   FROM AdventureWorksBackups
   WITH RECOVERY;

[В начало списка примеров]

Д.Копирование базы данных с помощью BACKUP и RESTORE

В следующем примере с помощью инструкций BACKUP и RESTORE создается копия базы данных AdventureWorks2012 . Инструкция MOVE восстанавливает файлы данных и журнала в указанные места. Количество и имена восстанавливаемых файлов базы данных можно определить с помощью инструкции RESTORE FILELISTONLY. Новая копия базы данных называется TestDB. Дополнительные сведения см. в разделе Инструкция RESTORE FILELISTONLY (Transact-SQL).

BACKUP DATABASE AdventureWorks2012 
   TO AdventureWorksBackups ;

RESTORE FILELISTONLY 
   FROM AdventureWorksBackups ;

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

[В начало списка примеров]

Е.Восстановление состояния на определенный момент времени с помощью STOPAT

В следующем примере база данных восстанавливается в состояние на 12:00 AMApril 15, 2020 и демонстрируется операция восстановления, использующая несколько резервных копий журналов. На устройстве резервного копирования AdventureWorksBackups полная резервная копия базы данных, подлежащей восстановлению, — это третий резервный набор данных на устройстве (FILE = 3), резервная копия первого журнала — это четвертый резервный набор (FILE = 4), резервная копия второго журнала — это пятый резервный набор (FILE = 5).

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

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

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

[В начало списка примеров]

Ж.Восстановление журнала транзакций до метки

В следующем примере журнал транзакций восстанавливается до метки в помеченной транзакции с именем ListPriceUpdate.

USE AdventureWorks2012
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 AdventureWorks2012
FROM AdventureWorksBackups
WITH FILE = 3, NORECOVERY;
GO

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

[В начало списка примеров]

З.Восстановление с использованием синтаксиса TAPE

В следующем примере производится восстановление базы данных из полной резервной копии, находящейся на устройстве резервного копирования TAPE.

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

[В начало списка примеров]

И.Восстановление с использованием синтаксиса FILE и FILEGROUP

В следующем примере производится восстановление базы данных MyDatabase, содержащей два файла, одну вторичную файловую группу и один журнал транзакций. Эта база данных использует модель полного восстановления.

Резервная копия базы данных представляет собой девятый резервный набор данных в наборе носителей на логическом устройстве резервного копирования с именем MyDatabaseBackups. Затем производится восстановление трех резервных копий журнала из следующих трех резервных наборов данных (10, 11 и 12) на устройстве MyDatabaseBackups с помощью предложения WITH NORECOVERY. База данных будет восстановлена после восстановления последней резервной копии журналов.

Примечание

Восстановление выполняется как отдельный шаг с целью снижения возможности преждевременного восстановления по журналу, до того как будут восстановлены все резервные копии журналов.

Обратите внимание на два типа параметров FILE в инструкции RESTORE DATABASE. Параметры FILE, предшествующие имени устройства резервного копирования, указывают логические имена файлов базы данных, которые будут восстановлены из резервного набора данных, например FILE = 'MyDatabase_data_1'. Этот резервный набор данных не является первой резервной копией базы данных в наборе носителей, поэтому его позиция указывается параметром FILE в предложении WITH: 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

[В начало списка примеров]

Л.Возврат из моментального снимка базы данных

В следующем примере производится восстановление базы данных к моментальному снимку базы данных. В этом примере предполагается, что в базе данных в настоящее время существует только один моментальный снимок. Пример создания этого моментального снимка базы данных см. в разделе создать моментальный снимок базы данных (Transact-SQL).

Примечание

Восстановление до моментального снимка удаляет все полнотекстовые каталоги.

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

Дополнительные сведения см. в разделе Восстановление базы данных до состояния, сохраненного в моментальном снимке.

[В начало списка примеров]

См. также

Справочник

BACKUP (Transact-SQL)

RESTORE REWINDONLY (Transact-SQL)

RESTORE VERIFYONLY (Transact-SQL)

Основные понятия

Резервное копирование и восстановление баз данных SQL Server

Резервное копирование и восстановление системных баз данных (SQL Server)

Создание резервных копий и восстановление полнотекстовых каталогов и индексов

Создание резервной копии и восстановление из копий реплицируемых баз данных

Наборы носителей, семейства носителей и резервные наборы данных (SQL Server)

Журнал и сведения о заголовке резервной копии (SQL Server)