Инструкции RESTORE (Transact-SQL)

  • Статья

Восстанавливает резервные копии баз данных SQL, созданные с помощью команды BACKUP.

Выбор продукта

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

Дополнительные сведения о соглашениях о синтаксисе см. в статье Соглашения о синтаксисе в Transact-SQL.

* SQL Server *  

Управляемый экземпляр SQL

Analytics Platform
System (PDW)

 

SQL Server

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

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

Другие ресурсы

Синтаксис

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

<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 }
 | [ METADATA_ONLY | SNAPSHOT ] [ DBNAME = { database_name | @database_name_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 поддерживает разные сценарии восстановления.

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

Примечание.

При оперативном восстановлении могут использоваться отложенные транзакции.

Дополнительные сведения см. в статье Восстановление в сети (SQL Server).

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

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

Следующие ключевые слова были прекращены в SQL Server 2008 (10.0.x):

Неподдерживаемое ключевое слово Заменены на... Пример заменяющего ключевого слова
LOAD RESTORE RESTORE DATABASE
ТРАНЗАКЦИЯ ЖУРНАЛ 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).

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

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

Примечание.

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

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

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

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

Замечания

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

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

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

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

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

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

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

Интегрированное ускорение и разгрузка для сжатия и распаковки резервных копий

В версии SQL Server 2022 (16.x) представлен ALGORITHM, который определяет алгоритм сжатия для операции. Дополнительные сведения о сжатии см. в статье Сжатие резервной копии.

Дополнительные сведения приведены в разделе Операция восстановления.

Восстановление из URL-адреса

URL-адрес — это формат, который используется для указания расположения и имени файла для хранилища BLOB-объектов Microsoft Azure или совместимого с S3 хранилища объектов. Хотя хранилище BLOB-объектов Azure является службой, реализация аналогична дисковому и ленточному хранилищу, чтобы обеспечить единообразное и эффективное восстановление для всех устройств.

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

Параметры базы данных и восстановление

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

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

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

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

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

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

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

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

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

Примечание.

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

Восстановление до SQL Server 2022 и функция автоматического удаления

При восстановлении базы данных в SQL Server 2022 (16.x) из предыдущей версии рекомендуется выполнить sp_updatestats в базе данных соответствующие метаданные для функции автоматического удаления статистики. Дополнительные сведения см. в разделе "Автоматическое удаление статистики".

Кластеры больших данных SQL Server

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

Инструкции см. в разделе Подключение к базам данных в первичной реплике.

Метаданные

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ограничения на отмену изменений

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

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

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

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

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

Внимание

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

Разрешения

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

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

Примеры

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

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

Примечание.

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

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

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

RESTORE DATABASE AdventureWorks2022
  FROM AdventureWorks2022Backups;

Примечание.

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

[Начало примеров]

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

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

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

[Начало примеров]

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

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

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

[Начало примеров]

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

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

RESTORE DATABASE AdventureWorks2022
    FROM AdventureWorksBackups
    WITH NORECOVERY,
      MOVE 'AdventureWorks2022_Data' TO
'C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\Data\NewAdvWorks.mdf',
      MOVE 'AdventureWorks2022_Log'
TO 'C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\Data\NewAdvWorks.ldf';
RESTORE LOG AdventureWorks2022
    FROM AdventureWorksBackups
    WITH RECOVERY;

[Начало примеров]

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

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

BACKUP DATABASE AdventureWorks2022
    TO AdventureWorksBackups ;

RESTORE FILELISTONLY
    FROM AdventureWorksBackups ;

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

[Начало примеров]

F. Восстановление до точки во времени с помощью STOPAT

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

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

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

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

[Начало примеров]

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

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

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

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

[Начало примеров]

H. Восстановление с помощью синтаксиса TAPE

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

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

[Начало примеров]

I. Восстановление с помощью синтаксиса FILE и FILEGROUP

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

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

Примечание.

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

Обратите внимание на два типа параметров RESTORE DATABASE в инструкции FILE. Параметры 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

[Начало примеров]

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

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

Примечание.

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

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

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

[Начало примеров]

K. Восстановление из хранилища BLOB-объектов Microsoft Azure

В следующих трех примерах используется служба хранилища Microsoft Azure. Имя учетной записи хранилища — mystorageaccount. Контейнер для файлов данных называется myfirstcontainer. Контейнер для файлов резервных копий называется mysecondcontainer. Хранимая политика доступа была создана с правами на чтение, запись, удаление и составление списков для каждого контейнера. Учетные данные SQL Server были созданы с использованием подписанных URL-адресов, которые связаны с хранимыми политиками доступа. Для получения сведений о резервном копировании и восстановлении SQL Server в хранилище BLOB-объектов Microsoft Azure см. Резервное копирование и восстановление SQL Server с помощью службы хранилища BLOB-объектов Microsoft Azure.

K1. Восстановление полной резервной копии базы данных из службы хранилища Microsoft Azure
Полная резервная копия базы данных в mysecondcontainer из Sales будет восстановлена в myfirstcontainer. Sales в настоящее время не существует на сервере.

RESTORE DATABASE Sales
  FROM URL = 'https://mystorageaccount.blob.core.windows.net/mysecondcontainer/Sales.bak'
  WITH MOVE 'Sales_Data1' to 'https://mystorageaccount.blob.core.windows.net/myfirstcontainer/Sales_Data1.mdf',
  MOVE 'Sales_log' to 'https://mystorageaccount.blob.core.windows.net/myfirstcontainer/Sales_log.ldf',
  STATS = 10;

K2. Восстановление полной резервной копии базы данных из службы хранилища Microsoft Azure в локальное хранилище Полная резервная копия базы данных в mysecondcontainer из Sales будет восстановлена в локальное хранилище. Sales в настоящее время не существует на сервере.

RESTORE DATABASE Sales
  FROM URL = 'https://mystorageaccount.blob.core.windows.net/mysecondcontainer/Sales.bak'
  WITH MOVE 'Sales_Data1' to 'H:\DATA\Sales_Data1.mdf',
  MOVE 'Sales_log' to 'O:\LOG\Sales_log.ldf',
  STATS = 10;

K3. Восстановление полной резервной копии базы данных из локального хранилища в службу хранилища Microsoft Azure

RESTORE DATABASE Sales
  FROM DISK = 'E:\BAK\Sales.bak'
  WITH MOVE 'Sales_Data1' to 'https://mystorageaccount.blob.core.windows.net/myfirstcontainer/Sales_Data1.mdf',
  MOVE 'Sales_log' to 'https://mystorageaccount.blob.core.windows.net/myfirstcontainer/Sales_log.ldf',
  STATS = 10;

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

Впервые представлено в SQL Server 2022 (16.x). Дополнительные сведения см. в статье "Создание резервного копирования моментальных снимков Transact-SQL".

L1. Восстановление полной резервной копии

RESTORE DATABASE Sales
  FROM DISK = 'D:\MSSQL\Backup\SalesSnapshotFull.bkm'
  WITH METADATA_ONLY;

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

RESTORE DATABASE Sales
  FROM DISK = 'D:\MSSQL\Backup\SalesSnapshotFull.bkm'
  WITH METADATA_ONLY,
  NORECOVERY;

RESTORE LOG Sales
  FROM DISK = 'D:\MSSQL\Backup\SalesLog.trn'
  WITH RECOVERY;

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

RESTORE DATABASE Sales
FROM DISK = 'D:\MSSQL\Backup\SalesSnapshotFull.bkm'
WITH METADATA_ONLY,
    MOVE Sales_Data TO 'D:\MSSQL\Sales.mdf',
    MOVE Sales_Log TO 'D:\MSSQL\Sales_log.ldf';

[Начало примеров]

Следующие шаги

SQL Server

* Управляемый экземпляр SQL *

Analytics Platform
System (PDW)

 

Управляемый экземпляр SQL Azure

Эта команда позволяет восстановить всю базу данных из полной резервной копии (полное восстановление) в учетной записи хранилища BLOB-объектов Azure.

Другие поддерживаемые команды RESTORE:

Внимание

Сведения о восстановлении из автоматических резервных копий Управляемого экземпляра SQL Azure см. в статье Восстановление базы данных SQL.

Синтаксис

--To Restore an Entire Database from a Full database backup (a Complete Restore):
RESTORE DATABASE { database_name | @database_name_var }
 FROM URL = { 'physical_device_name' | @physical_device_name_var } [ ,...n ]
[;]

Аргументы

DATABASE

Указывает целевую базу данных.

FROM URL

Указывает одно устройство резервного копирования или несколько по URL-адресам, которые будут использоваться для операции восстановления. Формат URL-адреса используется для восстановления резервных копий из службы хранилища Microsoft Azure.

Внимание

Чтобы выполнить восстановление с нескольких устройств при помощи URL-адреса, необходимо использовать токены подписанных URL-адресов (SAS). Примеры создания подписанного URL-адреса см. в разделах Резервное копирование SQL Server на URL-адрес и Упрощение создания учетных данных SQL с токенами подписанных URL-адресов в хранилище Azure с помощью Powershell.

n — заполнитель, который показывает, что можно указать до 64 устройств резервного копирования через запятую.

Замечания

Перед началом необходимо создать учетные данные с именем, совпадающим с URL-адресом учетной записи хранения BLOB-объектов и подписанным URL-адресом, сохраненным в виде секрета. Команда RESTORE выполнит поиск учетных данных с помощью URL-адреса хранилища BLOB-объектов, чтобы найти сведения, необходимые для считывания данных с устройства резервного копирования.

Операция RESTORE асинхронна и будет продолжаться даже в случае разрыва соединения с клиентом. В случае разрыва соединения вы можете просмотреть состояние операции восстановления (а также инструкций CREATE и DROP для базы данных) в представлении sys.dm_operation_status.

Следующие параметры базы данных устанавливаются или переопределяются и в последующем не могут быть изменены:

  • NEW_BROKER (если брокер не включен в BAK-файле)
  • ENABLE_BROKER (если брокер не включен в BAK-файле)
  • AUTO_CLOSE=OFF (если для базы данных в BAK-файле установлен параметр AUTO_CLOSE=ON)
  • RECOVERY FULL (если база данных в файле .bak имеет простую или BULK_LOGGED модель восстановления)
  • Добавляется оптимизированная для операций в памяти файловая группа с названием XTP (если она отсутствовала в исходном BAK-файле). Любые существующие оптимизированные для операций в памяти файловые группы переименовываются в XTP
  • Параметры SINGLE_USER и RESTRICTED_USER преобразуются в MULTI_USER

Ограничения — Управляемый экземпляр SQL

Применяются следующие ограничения:

  • BAK-файлы, содержащие несколько резервных наборов данных, не могут быть восстановлены.
  • BAK-файлы, содержащие несколько файлов журнала, не могут быть восстановлены.
  • Если BAK-файл содержит данные FILESTREAM, восстановление завершится сбоем.
  • Резервные копии, которые содержат базы данных с активными объектами в памяти, невозможно восстановить на уровне производительности "Общего назначения".
  • На данный момент невозможно восстановление резервных копий, которые содержат базы данных, находящиеся в режиме только для чтения.

Дополнительные сведения см. в статье Управляемый экземпляр SQL Azure.

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

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

Разрешения

У пользователя должны быть разрешения CREATE DATABASE, чтобы он имел возможность выполнять восстановление.

CREATE LOGIN mylogin WITH PASSWORD = 'Very Strong Pwd123!';
GRANT CREATE ANY DATABASE TO [mylogin];

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

Примеры

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

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

-- Create credential
CREATE CREDENTIAL [https://mybackups.blob.core.windows.net/wide-world-importers]
WITH IDENTITY = 'SHARED ACCESS SIGNATURE',
      SECRET = 'sv=2017-11-09&ss=bq&srt=sco&sp=rl&se=2022-06-19T22:41:07Z&st=2018-06-01T14:41:07Z&spr=https&sig=s7wddcf0w%3D';
GO
-- Restore database
RESTORE DATABASE WideWorldImportersStandard
FROM URL = N'https://mybackups.blob.core.windows.net/wide-world-importers/00-WideWorldImporters-Standard.bak',
URL = N'https://mybackups.blob.core.windows.net/wide-world-importers/01-WideWorldImporters-Standard.bak',
URL = N'https://mybackups.blob.core.windows.net/wide-world-importers/02-WideWorldImporters-Standard.bak',
URL = N'https://mybackups.blob.core.windows.net/wide-world-importers/03-WideWorldImporters-Standard.bak'

Следующая ошибка отображается, если база данных уже существует: Msg 1801, Level 16, State 1, Line 9 Database 'WideWorldImportersStandard' already exists. Choose a different database name.

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

DECLARE @db_name sysname = 'WideWorldImportersStandard';
DECLARE @url nvarchar(400) = N'https://mybackups.blob.core.windows.net/wide-world-importers/WideWorldImporters-Standard.bak';

RESTORE DATABASE @db_name
FROM URL = @url

C. Отслеживание хода выполнения инструкции RESTORE

SELECT query = a.text, start_time, percent_complete,
    eta = dateadd(second,estimated_completion_time/1000, getdate())
FROM sys.dm_exec_requests r
    CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) a
WHERE r.command = 'RESTORE DATABASE'

Примечание.

В этом представлении, вероятно, будут отображаться два запроса на восстановление: исходная инструкция RESTORE, поступившая от клиента, и фоновая инструкция RESTORE, выполняемая даже в случае разрыва соединения с клиентом.

SQL Server

Управляемый экземпляр SQL

* Analytics
Platform System (PDW) *

 

Система платформы аналитики

Восстанавливает пользовательскую базу данных Analytics Platform System (PDW) из резервной копии базы данных на устройство Analytics Platform System (PDW). База данных восстанавливается из резервной копии, созданной ранее с помощью команды Analytics Platform System (PDW) BACKUP DATABASE - Analytics Platform System. Используйте команды резервного копирования и восстановления для создания плана аварийного восстановления или для перемещения баз данных с одного устройства на другое.

Примечание.

Восстановление системной базы данных master включает восстановление сведений о входе устройства. Чтобы восстановить базу данных master, воспользуйтесь страницей Восстановление базы данных master средства Диспетчер конфигураций. Эту операцию может выполнить администратор, у которого есть доступ к управляющему узлу. Дополнительные сведения о резервном копировании баз данных Analytics Platform System (PDW) см. в разделе "Резервное копирование и восстановление" в документации по Системе платформы аналитики (PDW).

Синтаксис

-- Restore the master database
-- Use the Configuration Manager tool.

Restore a full user database backup.
RESTORE DATABASE database_name
    FROM DISK = '\\UNC_path\full_backup_directory'
[;]

--Restore a full user database backup and then a differential backup.
RESTORE DATABASE database_name
    FROM DISK = '\\UNC_path\differential_backup_directory'
    WITH [ ( ] BASE = '\\UNC_path\full_backup_directory' [ ) ]
[;]

--Restore header information for a full or differential user database backup.
RESTORE HEADERONLY
    FROM DISK = '\\UNC_path\backup_directory'
[;]

Аргументы

RESTORE DATABASE имя_базы_данных

Указывает, что нужно восстановить пользовательскую базу данных в базу данных с заданным именем. Восстановленная база данных может иметь имя, отличное от имени базы данных-источника, из которой создавалась резервная копия. База данных database_name не должна существовать на целевом устройстве. Дополнительные сведения о разрешенных именах баз данных см. в разделе "Правила именования объектов" в документации по Analytics Platform System (PDW).

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

FROM DISK = '\\UNC_path\backup_directory'

Сетевой путь к каталогу, из которого Система платформы аналитики (PDW) восстановит файлы резервной копии. Например, FROM DISK = '\\xxx.xxx.xxx.xxx\backups\2012\Monthly\08.2012.Mybackup'.

backup_directory. Указывает имя каталога, который содержит полную или разностную резервную копию. Например, операцию RESTORE HEADERONLY можно выполнить для полной или разностной резервной копии.

full_backup_directory. Указывает имя каталога, который содержит полную резервную копию.

differential_backup_directory. Указывает имя каталога, который содержит разностную резервную копию.

  • Путь к каталогу резервного копирования должен существовать; его необходимо указать в виде полного пути UNC.
  • Путь к каталогу резервного копирования не может быть локальным путем, и он не может быть расположением на любом узле устройства платформы аналитики (PDW).
  • Максимальная длина пути UNC и имени каталога резервного копирования равна 200 символов.
  • Для сервера или узла необходимо указать IP-адрес.

инструкция RESTORE HEADERONLY

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

Результаты инструкции RESTORE HEADERONLY обрабатываются в соответствии с шаблоном после результатов инструкции RESTORE HEADERONLY в SQL Server. Результат содержит более 50 столбцов, не все из которых используются в Analytics Platform System (PDW). Описание столбцов в результатах, возвращаемых инструкцией RESTORE HEADERONLY в SQL Server, см. в статье Инструкции RESTORE — HEADERONLY (Transact-SQL).

Разрешения

Требуется разрешение CREATE ANY DATABASE.

Требуется учетная запись Windows с разрешениями на доступ к каталогу резервного копирования и на чтение этого каталога. Кроме того, необходимо сохранить имя учетной записи Windows и пароль в системе платформы Аналитики (PDW).

Обработка ошибок

Команда RESTORE DATABASE возвращает ошибки при выполнении следующих условий:

  • Имя базы данных для восстановления уже существует на целевом устройстве. Чтобы избежать этой ошибки, выберите уникальное имя базы данных или удалите существующую базу данных перед началом восстановления.
  • В каталоге резервной копии находится недопустимый набор файлов резервной копии.
  • Разрешений на вход недостаточно для восстановления базы данных.
  • Analytics Platform System (PDW) не имеет необходимых разрешений для сетевого расположения, в котором размещаются файлы резервной копии.
  • Сетевое расположение для каталога резервного копирования не существует или недоступно.
  • На вычислительных узлах или на управляющем узле недостаточно места. Analytics Platform System (PDW) не проверяет наличие места на диске устройства перед началом восстановления. Поэтому при выполнении инструкции RESTORE DATABASE можно получить сообщение о нехватке места на диске. В случае нехватки места на диске Analytics Platform System (PDW) выполняет откат восстановления.
  • Целевое устройство, на которое восстанавливается база данных, содержит меньшее количество вычислительных узлов по сравнению с исходным устройством, с которого была создана резервная копия.
  • Предпринимается попытка восстановить базу данных в рамках транзакции.

Замечания

Analytics Platform System (PDW) отслеживает успешность восстановления базы данных. Перед восстановлением разностной резервной копии базы данных Analytics Platform System (PDW) проверяет, что полное восстановление всей базы данных успешно завершено.

После восстановления базы данных пользовательская база данных будет иметь уровень совместимости 120. Это справедливо для всех баз данных независимо от их исходного уровня совместимости.

Восстановление на устройство с большим количеством вычислительных узлов

Запустите инструкцию DBCC SHRINKLOG (Azure Synapse Analytics) после восстановления базы данных с устройства меньшего размера на устройство большего размера, так как при таком перемещении увеличится размер журнала транзакций.

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

Например, при восстановлении базы данных размером 60 ГБ с устройства с двумя узлами (30 ГБ на каждом узле) на устройство с шестью узлами Analytics Platform System (PDW) создает базу данных размером 180 ГБ (6 узлов по 30 ГБ на каждом узле) на устройстве с шестью узлами. Изначально Analytics Platform System (PDW) восстанавливает базу данных на 2 узлах, чтобы конфигурация соответствовала исходной, а затем перераспределяет данные на все 6 узлов.

После распределения каждый вычислительный узел будет содержать меньше фактических данных и больше свободного пространства, чем каждый исходный узел на исходном устройстве меньшего размера. Используйте дополнительное место для добавления дополнительных данных в базу данных. Если размер восстановленной базы данных больше, чем вам нужно, можно сжать файлы базы данных с помощью инструкции ALTER DATABASE - PDW.

ограничения

В этих ограничениях исходное устройство — это устройство, с которого была создана резервная копия базы данных, а целевое устройство — это устройство, на которое будет восстановлена база данных.

  • При восстановлении базы данных статистика не пересчитывается автоматически.
  • На одном устройстве в один момент времени может быть запущена только одна из инструкций RESTORE DATABASE или BACKUP DATABASE. Если одновременно было отправлено несколько инструкций резервного копирования и восстановления, устройство поместит их в очередь и будет обрабатывать их по одной.
  • Восстановить резервную копию базы данных можно только на целевое устройство Analytics Platform System (PDW), количество вычислительных узлов на котором не меньше количества узлов на исходном устройстве. Количество вычислительных узлов на целевом устройстве не может быть меньше количества вычислительных узлов на исходном устройстве.
  • Вы не можете восстановить резервную копию, которая была создана на устройстве с оборудованием SQL Server 2012 PDW, на устройство с оборудованием SQL Server 2008 R2. Это справедливо даже в том случае, если устройство было изначально приобретено с оборудованием SQL Server 2008 R2 PDW, а сейчас на нем запущено программное обеспечение SQL Server 2012 PDW.

Блокировка

Осуществляет монопольную блокировку объекта DATABASE.

Примеры

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

В следующем примере восстанавливается полная резервная копия в базу данных SalesInvoices2013. Файлы резервной копии хранятся в каталоге \\\xxx.xxx.xxx.xxx\backups\yearly\Invoices2013Full. База данных SalesInvoices2013 не может существовать на целевом устройстве, в противном случае команда завершится с ошибкой.

RESTORE DATABASE SalesInvoices2013
FROM DISK = '\\xxx.xxx.xxx.xxx\backups\yearly\Invoices2013Full';

B. Восстановление полной и разностной резервной копии

В следующем примере восстанавливается полная и разностная резервная копия в базу данных SalesInvoices2013

Полная резервная копия базы данных восстанавливается из полной резервной копии, которая хранится в каталоге \\\xxx.xxx.xxx.xxx\backups\yearly\Invoices2013Full. Если восстановление завершится успешно, разностная резервная копия восстанавливается в базу данных SalesInvoices2013. Разностная резервная копия хранится в каталоге \\\xxx.xxx.xxx.xxx\backups\yearly\Invoices2013Diff.

RESTORE DATABASE SalesInvoices2013
    FROM DISK = '\\xxx.xxx.xxx.xxx\backups\yearly\Invoices2013Diff'
    WITH BASE = '\\xxx.xxx.xxx.xxx\backups\yearly\Invoices2013Full'
[;]

C. Восстановление заголовка резервной копии

В этом примере восстанавливаются сведения о заголовке для резервного копирования для базы данных \\\xxx.xxx.xxx.xxx\backups\yearly\Invoices2013Full. Результаты выполнения команды в одной строке для резервной копии Invoices2013Full.

RESTORE HEADERONLY
    FROM DISK = '\\xxx.xxx.xxx.xxx\backups\yearly\Invoices2013Full'
[;]

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

Следующие шаги