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

Обновление доставки журналов до SQL Server 2012 (Transact-SQL)

  • Статья

При обновлении с SQL Server 2005, SQL Server 2008 или SQL Server 2008 R2 до SQL Server 2012 конфигурацию доставки журналов можно сохранить. В этом разделе описаны альтернативные сценарии и рекомендации по обновлению конфигурации доставки журналов.

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

Сжатие резервной копии было введено в выпуске SQL Server 2008 Enterprise. В обновленной конфигурации доставки журналов используется параметр конфигурации backup compression default уровня сервера, который управляет применением сжатия резервной копии к файлам резервной копии журнала транзакций. Режим сжатия резервной копии журналов можно указать отдельно для каждой конфигурации доставки журналов. Дополнительные сведения см. в разделе Настройка доставки журналов (SQL Server).

В этом разделе:

  • Защита данных перед обновлением

  • Обновление экземпляра сервера мониторинга

  • Обновление конфигурации доставки журналов с одним сервером-получателем

  • Обновление нескольких экземпляров серверов-получателей

  • Повторное развертывание доставки журналов

Защита данных перед обновлением

Рекомендуется защищать данные перед обновлением доставки журналов.

Защита данных

  1. Создайте полную резервную копию каждой базы данных-источника.

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

  2. Выполните команду DBCC CHECKDB в каждой базе данных-источнике.

Обновление экземпляра сервера мониторинга

Существующий экземпляр сервера мониторинга можно обновить в любой момент.

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

Обновление конфигурации доставки журналов с одним сервером-получателем

Процесс обновления, описанный в этом разделе, предполагает работу с конфигурацией, которая состоит из сервера-источника и единственного сервера-получателя. Эта конфигурация показана на следующей иллюстрации, на которой изображен экземпляр сервера-источника (A) и экземпляр единственного сервера-получателя (Б).

Один сервер-получатель, нет сервера мониторинга

Сведения об обновлении нескольких серверов-получателей см. в подразделе Обновление нескольких экземпляров серверов-получателей далее в этом разделе.

В этом разделе.

  • Обновление экземпляра сервера-получателя

  • Обновление экземпляра сервера-источника

Обновление экземпляра сервера-получателя

Перед обновлением экземпляра сервера-источника обновляется конфигурация доставки журналов экземпляров серверов-получателей с SQL Server 2005, SQL Server 2008 или SQL Server 2008 R2 до версии SQL Server 2012. Экземпляр сервера-получателя всегда следует обновлять первым. Если бы сервер-источник обновлялся до сервера-получателя, то доставка журналов стала бы невозможна, поскольку более старую версию SQL Server нельзя восстановить из резервной копии, созданной в новой версии SQL Server.

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

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

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

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

В процессе обновления сервера база данных-получатель не обновляется до версии SQL Server 2012. Ее обновление происходит только при переключении в режим «в сети».
Важное примечаниеВажно!

Параметр RESTORE WITH STANDBY не поддерживается для базы данных, требующей обновления. Если обновленная база данных-получатель была настроена при помощи RESTORE WITH STANDBY, то журналы транзакций нельзя восстановить после обновления. Чтобы возобновить доставку журналов на базу данных-получатель, необходимо заново настроить доставку журналов на резервном сервере. Дополнительные сведения о параметре STANDBY см. в разделе Аргументы инструкции RESTORE (Transact-SQL).

Обновление экземпляра сервера-источника

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

Добиться максимальной доступности базы данных можно за счет усложнения процесса обновления. Для этого перед обновлением исходного сервера-источника нужно выполнить переход с сервера-источника SQL Server 2005, SQL Server 2008 или SQL Server 2008 R2 на сервер-получатель SQL Server 2012 (приведенный ниже сценарий 2). Существует два возможных сценария отработки отказа. Можно переключиться назад на исходный сервер-источник и сохранить первоначальную конфигурацию доставки журналов. В качестве альтернативного варианта можно удалить исходную конфигурацию доставки журналов до обновления исходного сервера-источника и позднее создать новую конфигурацию с помощью нового сервера-источника. В этом разделе описываются оба сценария.

Важное примечаниеВажно!

Экземпляр сервера-получателя следует обновлять обязательно до экземпляра сервера-источника. Дополнительные сведения см. в подразделе Обновление экземпляра сервера-получателя ранее в этом разделе.

В этом разделе.

  • Сценарий 1. Обновление экземпляра сервера-источника без отработки отказа

  • Сценарий 2. Обновление экземпляра сервера-источника с отработкой отказа

Сценарий 1. Обновление экземпляра сервера-источника без отработки отказа

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

Как только обновление сервера завершается, база данных автоматически переводится обратно в режим «в сети», в результате чего обновляется сама. После обновления базы данных возобновляют работу задания доставки журналов.

Сценарий 2. Обновление экземпляра сервера-источника с отработкой отказа

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

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

Важное примечаниеВажно!

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

В этом разделе.

  • Процедура 1. Выполните управляемую отработку отказа на сервер-получатель

  • Процедура 2. Обновление исходного экземпляра сервера-источника до версии SQL Server 2012

  • Процедура 3. Настройка доставки журналов в SQL Server 2012

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

Управляемая отработка отказа на сервер-получатель.

  1. Вручную создайте резервную копию заключительного фрагмента журнала транзакций в базе данных-источнике, указав предложение WITH NORECOVERY. В эту резервную копию журналов попадут все записи, резервная копия которых еще не была создана, и база данных будет отключена. Обратите внимание, что пока база данных находится в режиме «вне сети», задание резервного копирования в доставке журналов будет завершаться с ошибкой.

    В приведенном ниже примере создается резервная копия заключительного фрагмента журнала базы данных AdventureWorks на сервере-источнике. Файлу резервной копии присваивается имя Failover_AW_20080315.trn:

    BACKUP LOG AdventureWorks 
  TO DISK = N'\\FileServer\LogShipping\AdventureWorks\Failover_AW_20080315.trn' 
   WITH NORECOVERY;
GO

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

  2. На сервере-получателе сделайте следующее.

    1. Убедитесь, что применены все резервные копии, созданные автоматически заданиями резервного копирования в доставке журналов. Проверить, какие задания резервного копирования были применены, можно с помощью системной процедуры sp_help_log_shipping_monitor на сервере мониторинга либо на сервере-источнике или сервере-получателе. Тот же файл должен быть указан в столбцах last_backup_file, last_copied_file и last_restored_file. Если какой-то из файлов резервной копии не был скопирован или из него не было выполнено восстановление, вручную вызовите задания копирования и восстановления агента для конфигурации доставки журналов.

      Дополнительные сведения о запуске задания см. в разделе Запуск задания.

    2. Скопируйте заключительный файл резервной копии журнала, созданный в шаге 1, из общей папки в локальное расположение, которое используется для доставки журналов на сервере-получателе.

    3. Восстановите заключительную резервную копию журнала, указав предложение WITH RECOVERY, чтобы перевести базу данных в режим «в сети». При переходе в режим «в сети» база данных будет обновлена до версии SQL Server 2012.

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

      RESTORE LOG AdventureWorks 
  FROM DISK = N'c:\logshipping\Failover_AW_20080315.trn' 
   WITH RECOVERY;
GO
      ПримечаниеПримечание

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

    4. Перевод базы данных на другой ресурс путем перенаправления клиентов с исходного сервера-источника (сервера A) на подключенный сервер-получатель (сервер B).

    5. Убедитесь, чтобы журнал транзакций базы данных-получателя не заполнялся, когда база данных находится в режиме «в сети». Чтобы предотвратить заполнение журнала транзакций, можно создать его резервную копию. То есть рекомендуется сохранить его резервную копию в общем расположении, общей папке резервных копий, чтобы резервные копии были доступны для восстановления из копии на другом экземпляре сервера.

Процедура 2. Обновите исходный экземпляр сервера-источника до версии SQL Server 2012

После обновления экземпляра исходного экземпляра сервера-источника до версии SQL Server 2012 база данных по-прежнему будет в режиме «вне сети» и в формате предыдущей версии.

Процедура 3. Настройка доставки журналов в SQL Server 2012

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

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

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

Переключение обратно на экземпляр исходного сервера-источника

  1. На промежуточном сервере-источнике (сервер B) создайте резервную копию заключительного фрагмента журнала с помощью параметра WITH NORECOVERY — будет создана резервная копия заключительного фрагмента журнала, а база данных перейдет в режим «вне сети». Резервная копия заключительного фрагмента журнала имеет имя Switchback_AW_20080315.trn. Например:

    BACKUP LOG AdventureWorks 
  TO DISK = N'\\FileServer\LogShipping\AdventureWorks\Switchback_AW_20080315.trn' 
   WITH NORECOVERY;
GO

  2. Если в промежуточной базе данных-источнике создавались резервные копии журналов транзакций, отличные от резервной копии заключительного фрагмента журнала, созданной в шаге 1, выполните восстановление из этих копий с помощью параметра WITH NORECOVERY для базы данных в режиме «вне сети» на исходном сервере-источнике (сервер A). База данных будет обновлена до формата SQL Server 2012 при восстановлении из первой же резервной копии журналов.

  3. Выполните восстановление из резервной копии заключительного фрагмента журнала (Switchback_AW_20080315.trn) в исходной базе данных-источнике (на сервере A) с помощью параметра WITH RECOVERY, чтобы перевести базу данных в режим в сети.

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

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

Сохранение экземпляра прежнего сервера-получателя в качестве экземпляра нового сервера-источника

Создайте новую конфигурацию доставки журналов, используя экземпляр прежнего сервера-получателя, сервера B, в качестве нового сервера-источника и прежнего экземпляра сервера-источника, сервера A, в качестве нового сервера-получателя.

Важное примечаниеВажно!

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

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

  2. Создание резервной копии журналов в новой базе данных-источнике (на сервере B).

  3. Восстановление из резервных копий журналов на экземпляре нового сервера-получателя (сервере A) с помощью параметра WITH NORECOVERY. В процессе первой же операции восстановления база данных обновляется до версии SQL Server 2012.

  4. Настройте доставку журналов с прежним сервером-получателем (сервером B) в качестве экземпляра сервера-источника.

    Важное примечаниеВажно!

    При работе в среде Среда SQL Server Management Studio следует указать, что база данных-получатель уже инициализирована.

    Дополнительные сведения см. в разделе Настройка доставки журналов (SQL Server).

  5. Перевод базы данных на другой ресурс путем перенаправления клиентов с исходного сервера-источника (сервера A) на подключенный сервер-получатель (сервер B).

    Важное примечаниеВажно!

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

Обновление нескольких экземпляров серверов-получателей

Эта конфигурация показана на следующей иллюстрации, на которой изображен экземпляр сервера-источника (A) и два экземпляра сервера-получателя (B и C).

Два сервера-получателя, нет сервера мониторинга

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

Важное примечаниеВажно!

Экземпляры сервера-получателя всегда следует обновлять раньше, чем сервер-источник.

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

  1. Обновите все экземпляры сервера-получателя (сервер B и сервер C).

  2. Получите заключительный фрагмент журнала транзакций базы данных-источника (на сервере A) и переведите базу данных в режим «вне сети» путем создания резервной копии журнала транзакций с помощью параметра WITH NORECOVERY.

  3. На сервере-получателе, на который планируется выполнять переход (сервер B), переведите базу данных-получатель в режим «в сети» путем восстановления из резервной копии журналов с помощью инструкции WITH RECOVERY.

  4. На каждом сервере-получателе (сервер C) следует перевести базу данных-получатель в режим «вне сети» путем восстановления из резервной копии журналов с помощью предложения WITH NORECOVERY.

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

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

  5. Перевод базы данных на другой ресурс путем перенаправления клиентов с исходного сервера-источника (сервера A) на подключенный сервер-получатель (сервер B). База данных в режиме «в сети» становится промежуточным сервером-источником, благодаря которому база остается доступной, пока исходный сервер-источник (сервер A) находится в режиме «вне сети».

  6. Обновите исходный сервер-источник (сервер A).

  7. В базе данных, на которую выполнен переход — промежуточную базу данных-источник (на сервере B), — вручную создайте резервную копию журнала транзакций с помощью параметра WITH NORECOVERY. При этом база данных перейдет в режим «вне сети».

  8. Выполните восстановление из всех резервных копий журналов транзакций, созданных в промежуточной базе данных-источнике (на сервере B) для всех прочих баз данных-получателей (на сервере C) с помощью параметра WITH NORECOVERY. Это позволяет продолжить доставку журналов из исходной базы данных-источника после ее обновления без необходимости выполнять полное восстановление в каждой базе данных-получателе.

  9. Восстановите журнал транзакций с промежуточного сервера-источника (сервера B) на исходной базе данных-источнике (на сервере A) с помощью параметра WITH RECOVERY.

Повторное развертывание доставки журналов

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

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

См. также

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

Резервные копии журналов транзакций (SQL Server)

Применение резервных копий журналов транзакций (SQL Server)

Таблицы доставки журналов и хранимые процедуры