RESTORE (Transact-SQL)

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

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

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

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

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

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

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

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

ПримечаниеПримечание

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

ПримечаниеПримечание

Начиная с версии SQL Server 2012 с пакетом обновления 1 (SP1) и накопительным обновлением CU2, поддерживается резервное копирование данных SQL Server в службу хранилищ больших двоичных объектов Windows Azure. Дополнительные сведения см. в разделах Улучшения резервного копирования и восстановления и Резервное копирование и восстановление SQL Server с помощью службы хранилищ больших двоичных объектов Windows Azure.

Значок ссылки на раздел Синтаксические обозначения в 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 } = { 'physical_backup_device_name' |
      @physical_backup_device_name_var } 
} 

<files_or_filegroups>::= 
{ 
   FILE = { logical_file_name_in_backup | @logical_file_name_in_backup_var } 
 | FILEGROUP = { logical_filegroup_name | @logical_filegroup_name_var } 
 | READ_WRITE_FILEGROUPS
} 

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

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

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

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

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

--Monitoring Options
 | STATS [ = percentage ] 

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

<change_data_capture_WITH_option>::=
 | KEEP_CDC

<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, компонент Ядро СУБД формирует ошибку.

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

В SQL Server 2012 вы можете восстановить пользовательскую базу данных из резервной копии базы данных, созданной с помощью SQL Server 2005 или более поздней версии. Однако восстановление резервных копий баз данных master, model и msdb, созданных в SQL Server 2005 или SQL Server 2008, в SQL Server 2012 невозможно. Кроме того, резервные копии, созданные в SQL Server 2012, невозможно восстановить в более ранних версиях SQL Server.

ПримечаниеПримечание

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

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

После восстановления базы данных SQL Server 2005 или SQL Server 2008 на SQL Server 2012 база данных автоматически обновляется. Как правило, база данных сразу становится доступной. Однако если база данных 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 2005 с пакетом обновления 2 (SP2) для каждого удаленного хранилища кэша в кэше планов журнал ошибок 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 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 должны располагаться в корневом каталоге, в котором создаются резервные копии.

Разрешения

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

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

Примеры

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

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

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

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

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

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

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

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

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

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

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

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

ПримечаниеПримечание

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

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

В следующем примере производится восстановление базы данных из полной резервной копии, находящейся на логическом устройстве резервного копирования на магнитной ленте 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\MSSQL11.MSSQLSERVER\MSSQL\Data.

RESTORE DATABASE AdventureWorks2012
   FROM AdventureWorksBackups
   WITH NORECOVERY, 
      MOVE 'AdventureWorks2012_Data' TO 
'C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\Data\NewAdvWorks.mdf', 
      MOVE 'AdventureWorks2012_Log' 
TO 'C:\Program Files\Microsoft SQL Server\MSSQL11.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)