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

  • Статья

Обновление доставки журналов SQL Server 2005 до SQL Server 2008

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

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

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

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

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

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

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

    Дополнительные сведения см. в разделах:

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

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

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

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

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

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

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

Сведения об обновлении нескольких серверов-получателей см. в подразделе «Замечания по обновлению нескольких серверов-получателей» далее в текущем разделе.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Процедура 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 (Transact-SQL) на сервере мониторинга либо на сервере-источнике или сервере-получателе. Один и тот же файл должен быть указан в столбцах last_backup_file, last_copied_file и last_restored_file. Если какой-то из файлов резервной копии не был скопирован или из него не было выполнено восстановление, вручную вызовите задания копирования и восстановления агента для конфигурации доставки журналов. Дополнительные сведения см. в разделах Как запустить задание (среда SQL Server Management Studio) и sp_start_job (Transact-SQL).

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

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

      В приведенном ниже примере выполняется восстановление из резервной копии заключительного фрагмента журнала базы данных 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 2008

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

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

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

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

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

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

  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 2008 при восстановлении из первой же резервной копии журналов.

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

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

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

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

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

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

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

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

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

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

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

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

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

    Настройка доставки журналов

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

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

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

Рекомендации по обновлению нескольких экземпляров сервера-получателя

Эта конфигурация показана на следующей иллюстрации, на которой изображен экземпляр сервера-источника (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 Management Studio см. в разделе Как включить доставку журналов (среда SQL Server Management Studio).

Дополнительные сведения о включении доставки журналов с помощью Transact-SQL см. в разделе Как включить доставку журналов (Transact-SQL).

Журнал изменений

Обновления

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