Создание резервной копии журнала транзакций (SQL Server). Журнал ms sql

Журнал транзакций (SQL Server)

 

Опубликовано: Ноябрь 2016

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

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

 Примечание

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

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

Журнал транзакций поддерживает следующие операции:

• восстановление отдельных транзакций;

• восстановление всех незавершенных транзакций при запуске SQL Server;

• накат восстановленной базы данных, файла, файловой группы или страницы до момента сбоя;

• поддержка репликации транзакций;

• Поддержка решений высокой уровня доступности и аварийного восстановления: Группы доступности AlwaysOn, зеркальное отображение базы данных и доставка журналов.

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

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

• В простой модели восстановления — после достижения контрольной точки.

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

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

 Примечание

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

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

Усечение журнала может быть задержано из-за множества факторов. Чтобы определить причину, препятствующую усечению журнала транзакций в конкретном случае, выполните запрос по столбцам log_reuse_wait и log_reuse_wait_desc представления каталога sys.database. В следующей таблице описаны значения этих столбцов.

Значение столбца log_reuse_waitЗначение столбца log_reuse_wait_descОписание

0	NOTHING;	В данный момент существует один или более виртуальных файлов журнала, доступных для повторного использования.
1	CHECKPOINT	С момента последнего усечения журнала не было новых контрольных точек, либо заголовок журнала не перемещался за пределы виртуального файла журнала. (Все модели восстановления) Это широко распространенная причина задержки усечения журнала. Дополнительные сведения см. в разделе Контрольные точки базы данных (SQL Server).
2	LOG_BACKUP	Требуется выполнить резервное копирование журналов, поскольку лишь после этого журнал транзакций может быть усечен. (Только для моделей полного восстановления и моделей восстановления с неполным протоколированием) После завершения создания следующей резервной копии журнала некоторое пространство журнала может освободиться для повторного использования.
3	ACTIVE_BACKUP_OR_RESTORE	Выполняется резервное копирование или восстановление данных (для всех моделей восстановления). Если усечению журнала препятствует резервное копирование данных, то проблему может решить отмена операции резервного копирования.
4	ACTIVE_TRANSACTION	Активна одна из транзакций (для всех моделей восстановления). - Во время начала создания резервной копии журнала может существовать длительная транзакция. В этом случае, чтобы освободить пространство, может потребоваться создание другой резервной копии журнала. Note: Длительные транзакции препятствуют усечению журнала во всех моделях восстановления, включая простую модель восстановления, в которой журнал транзакций обычно усекается на каждой автоматической контрольной точке.- Транзакция отложена.Отложенная транзакция — это активная транзакция, откат которой был заблокирован по причине недоступности какого-либо ресурса. Дополнительные сведения о причинах, вызывающих появление отложенных транзакций, и о том, как их можно вывести из такого состояния, см. в разделе Отложенные транзакции (SQL Server).
5	DATABASE_MIRRORING	Зеркальное отображение базы данных приостановлено или в режиме высокой производительности зеркальная база данных намного отстает от основной. (Только для модели полного восстановления) Дополнительные сведения см. в разделе Зеркальное отображение базы данных (SQL Server).
6	REPLICATION	Во время репликации транзакций в базу данных распространителя не доставляются транзакции, имеющие отношение к публикациям. (Только для модели полного восстановления) Дополнительные сведения о репликации транзакций см. в разделе Репликация SQL Server.
7	DATABASE_SNAPSHOT_CREATION	Создается моментальный снимок базы данных. (Все модели восстановления) Это очень распространенная (и обычно кратковременная) причина задержки усечения журнала транзакций.
8	LOG_SCAN	Производится просмотр журнала. (Все модели восстановления) Это очень распространенная (и обычно кратковременная) причина задержки усечения журнала транзакций.
9	AVAILABILITY_REPLICA	Вторичная реплика группы доступности применяет записи журнала транзакций этой базы данных к соответствующей базе данных-получателю. (Модель полного восстановления) Дополнительные сведения см. в разделе Обзор групп доступности AlwaysOn (SQL Server).
10	—	Только для внутреннего применения
11	—	Только для внутреннего применения
12	—	Только для внутреннего применения
13	OLDEST_PAGE	Если база данных настроена для использования косвенных контрольных точек, самая старая страница в базе данных может быть старше контрольной точки с номером LSN. В этом случае самая старая страница может задержать усечение журнала. (Все модели восстановления) Дополнительные сведения о косвенных контрольных точках см. в разделе Контрольные точки базы данных (SQL Server).
14	OTHER_TRANSIENT	Эта значение сейчас не используется.
16	XTP_CHECKPOINT	Если база данных имеет оптимизированную для памяти файловую группу, журнал транзакций может не усекаться до срабатывания автоматической контрольной точки In-Memory OLTP (что происходит при росте размера журнала на каждые 512 МБ). Note: Чтобы усечь размер журнала транзакций до достижения 512 МБ, выполните команду Checkpoint вручную для соответствующей базы данных.

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

 Примечание

Минимальное протоколирование не поддерживается для оптимизированных для памяти таблиц.

 Примечание

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

Следующие операции, выполняемые с полным протоколированием в модели полного восстановления, осуществляются с минимальным протоколированием в простой модели восстановления и модели восстановления с неполным протоколированием:

• Операции массового импорта (bcp, BULK INSERT и INSERT... SELECT). Дополнительные сведения о том, когда массовый импорт в таблицу подлежит минимальному протоколированию, см. в разделе Предварительные условия для минимального протоколирования массового импорта данных.

   Примечание

  Если включена репликация транзакций, операции BULK INSERT полностью протоколируются даже в модели с неполным протоколированием.

• Операции SELECT INTO.

   Примечание

  Если включена репликация транзакций, операции SELECT INTO полностью протоколируются даже в модели восстановления с неполным протоколированием.

• Частичные обновления типов данных с большими значениями с помощью предложений .WRITE инструкции UPDATE при вставке или добавлении новых данных. Обратите внимание, что минимальное протоколирование не используется при обновлении существующих значений. Дополнительные сведения о больших типах-значениях см. в разделе Типы данных (Transact-SQL).

• Инструкции WRITETEXT и UPDATETEXT при вставке или добавлении новых данных в столбцы с типом данных text, ntext и image. Обратите внимание, что минимальное протоколирование не используется при обновлении существующих значений.

   Примечание

  Инструкции WRITETEXT и UPDATETEXT являются устаревшими, поэтому следует избегать их использования в новых приложениях.

• Если в базе данных используется простая модель восстановления или модель восстановления с неполным протоколированием, некоторые DDL-операции с индексом протоколируются в минимальном объеме при их выполнении как режиме «вне сети», так и в режиме «в сети». Минимально протоколируются следующие операции с индексами.

  • Операции CREATE INDEX (включая индексированные представления).

  • Операции ALTER INDEX REBUILD или DBCC DBREINDEX.

     Примечание

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

  • Перестроение новой кучи DROP INDEX (если применимо).

     Примечание

    Освобождение страниц индекса в ходе выполнения операции DROP INDEX всегда протоколируется полностью.

Managing the transaction log

Резервное копирование журнала транзакций (модель полного восстановления)

Восстановление журнала транзакций (модель полного восстановления)

Управление устойчивостью транзакцийПредварительные условия для минимального протоколирования массового импорта данныхРезервное копирование и восстановление баз данных SQL ServerКонтрольные точки базы данных (SQL Server)Просмотр или изменение свойств базы данныхМодели восстановления (SQL Server)

technet.microsoft.com

просмотреть журнал ошибок агента SQL Server (среда SQL Server Management Studio)

Эта документация перемещена в архив и не поддерживается.

В этом разделе содержатся сведения о просмотре журнала ошибок агента SQL Server в SQL Server 2012 с помощью среды Среда SQL Server Management Studio.

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

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

Ограничения

Узел агента SQL Server отображается в обозревателе объектов только при наличии у пользователя разрешения на использование узла.

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

Разрешения

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

• Вход в систему в качестве службы (SeServiceLogonRight)

• Замена токена уровня процесса (SeAssignPrimaryTokenPrivilege)

• Обход проходной проверки (SeChangeNotifyPrivilege)

• Назначение квот памяти процессам (SeIncreaseQuotaPrivilege)

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

[Top]

Просмотр журнала ошибок агента SQL Server

1. В обозревателе объектов щелкните значок «плюс», чтобы развернуть сервер, содержащий журнал агента SQL Server, который необходимо просмотреть.

2. Щелкните знак «плюс», чтобы развернуть Агент SQL Server.

3. Щелкните значок «плюс», чтобы развернуть папку Журналы ошибок.

4. Щелкните правой кнопкой журнал ошибок, который необходимо просмотреть, и выберите Просмотреть журнал агента.

   В диалоговом окне Средство просмотра журнала —server_name доступны следующие параметры.

   Загрузить журнал

   Открывает диалоговое окно, в котором можно указать загружаемый файл журнала.

   Экспортировать

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

   Обновить

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

   Фильтр

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

   Поиск

   Позволяет найти определенный текст в файле журнала. Поиск с символами-шаблонами не поддерживается.

   Стоп

   Прекращает загрузку записей файла журнала. Например, можно использовать этот параметр, если загрузка удаленного файла или файла журнала вне сети занимает длительное время, а нужно просмотреть лишь наиболее свежие записи.

   Сводка по файлу журнала

   Эта информационная панель содержит сводку данных по фильтрации файла журнала. Если файл не фильтруется, на панели отображается текст без фильтров. Если фильтр применяется к журналу, отображается следующий текст Фильтрация записей журнала: <критерии фильтрации>».

   Сведения о выбранной строке

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

   Экземпляр

   Имя экземпляра, к которому относится происшедшее событие. Отображается в виде computer name\instance name.

   Дата

   Дата события.

   Источник

   Исходная функция, создавшая событие, например имя службы (MSSQLSERVER). Отображается не для всех типов журнала.

   Message

   Сообщение, связанное с событием.

   Log Type

   Отображает тип журнала, которому принадлежит событие. Все выбранные журналы отображаются в окне сводки файла журнала.

   Log Source

   Отображает описание исходного журнала, в котором зарегистрировано событие.

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

[Top]

technet.microsoft.com

Сведения о доставке журналов (SQL Server)

Эта документация перемещена в архив и не поддерживается.

SQL Server 2012

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

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

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

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

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

[В начало]

сервер-источник

Экземпляр SQL Server, являющийся рабочим сервером.

база данных-источник

База данных сервера-источника, резервную копию которой нужно создать на другом сервере. Все администрирование конфигурации доставки журналов через среду Среда SQL Server Management Studio производится на базе данных-источнике.

сервер-получатель

Экземпляр SQL Server, на котором нужно хранить «горячую» копию базы данных-источника.

база данных-получатель

«Горячая» копия базы данных-источника. База данных-получатель может находиться в состояниях RECOVERING или STANDBY, что означает, что она доступна в ограниченном режиме только для чтения.

сервер мониторинга

Необязательный экземпляр SQL Server, который отслеживает весь процесс доставки журналов, в том числе:

• когда резервная копия журнала транзакций на базе данных-источнике была сохранена в последний раз;

• когда серверы-получатели в последний раз копировали и восстанавливали файлы резервных копий;

• сведения о любых предупреждениях о сбоях.

Важно!

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

задание резервного копирования

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

задание копирования

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

задание восстановления

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

задание предупреждения

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

Совет

Для каждого предупреждения необходимо задать номер. Также необходимо настроить предупреждение для оповещения оператора при появлении этого предупреждения.

[В начало]

Доставка журналов состоит из этих трех операций:

1. резервное копирование журнала транзакций на экземпляре сервера-источника;

2. копирование резервных копий журнала транзакций на экземпляр сервера-получателя;

3. восстановление из резервных копий журнала транзакций на экземпляре сервера-получателя.

Журнал может доставляться нескольким экземплярам серверов-получателей. В этих случаях операции 2 и 3 повторяются для каждого экземпляра сервера-получателя.

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

Сервер-получатель можно использовать для построения отчетов.

Кроме того, можно настроить предупреждения в конфигурации доставки журналов.

Типичная конфигурация доставки журналов

Следующий рисунок показывает конфигурацию доставки журналов с экземпляром сервера-источника, тремя экземплярами сервера-получателя и экземпляром сервера мониторинга. Рисунок отображает шаги, выполняемые задачами резервного копирования, копирования и восстановления, следующим образом:

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

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

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

Экземпляры сервера-источника и сервера-получателя посылают собственный журнал и состояние экземпляру сервера мониторинга.

[В начало]

Доставка журналов может использоваться вместе со следующими функциями и компонентами SQL Server.

Примечание

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

[В начало]

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

technet.microsoft.com

Настройка доставки журналов (SQL Server)

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

В области Выбор страницы щелкните Доставка журналов транзакций.

Установите флажок Включить эту базу данных в качестве источника в конфигурацию доставки журналов.

В разделе Резервные копии журналов транзакций нажмите кнопку Параметры копирования.

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

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

Важно!

Если учетная запись служб SQL Server на сервере-источнике выполняется с правами учетной записи «Локальная система», надо создать папку резервного копирования на сервере-источнике и указать локальный путь к ней.

Настройте параметры Удалить файлы, созданные ранее и Предупредить, если резервное копирование не произошло в течение.

Обратите внимание на расписание в поле Расписание в разделе Задание резервного копирования. Если нужно изменить расписание, нажмите кнопку Расписание и задайте расписание для агента SQL Server по своему усмотрению.

Microsoft SQL Server 2012 Enterprise поддерживает сжатие резервных копий. При создании конфигурации доставки журналов можно управлять поведением сжатия резервных копий журналов, выбрав один из следующих параметров. Использовать параметр сервера по умолчанию, Сжимать резервные копии и Не сжимать резервные копии. Дополнительные сведения см. в разделе Настройки резервного копирования журналов транзакций для доставки журналов.

Нажмите кнопку ОК.

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

Нажмите Соединить и соединитесь с экземпляром SQL Server, который нужно использовать в качестве сервера-получателя.

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

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

Примечание

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

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

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

На вкладке Восстановление журнала транзакций в разделе Состояние базы данных во время восстановления резервных копий выберите пункт Без режима восстановления или Режим ожидания.

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

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

Выберите пороговое значение для предупреждения в поле Предупреждение, если восстановление не выполнено в течение.

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

Нажмите кнопку ОК.

В разделе Экземпляр сервера мониторинга выберите флажок Использовать экземпляр сервера мониторинга и затем нажмите кнопку Настройки.

Важно!

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

Нажмите кнопку Соединить и соединитесь с экземпляром компонента SQL Server, который нужно использовать в качестве сервера мониторинга.

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

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

Нажмите кнопку ОК.

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

msdn.microsoft.com

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

 

Опубликовано: Декабрь 2016

В этом разделе описано, как создать резервную копию журнала транзакций в SQL Server 2014 с помощью среды SQL Server Management Studio, Transact-SQLили PowerShell.

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

Ограничения

• Инструкция BACKUP не разрешена в явных и неявных транзакциях.

Рекомендации

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

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

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

Разрешения

Разрешения BACKUP DATABASE и BACKUP LOG назначены по умолчанию членам предопределенной роли сервера sysadmin и предопределенным ролям базы данных db_owner и db_backupoperator .

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

Создание резервной копии журнала транзакций

1. После подключения к соответствующему экземпляру компонента Компонент SQL Server Database Engineв обозревателе объектов разверните дерево сервера, щелкнув его имя.

2. Раскройте узел Базы данныхи в зависимости от типа восстанавливаемой базы данных выберите пользовательскую базу данных или раскройте узел Системные базы данных и выберите системную базу данных.

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

4. В списке База данных проверьте имя базы данных. При необходимости можно выбрать другую базу данных из списка.

5. Убедитесь в том, что используется либо модель восстановления FULL , либо BULK_LOGGED.

6. Выберите Журнал транзакций в списке Тип резервного копирования.

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

    Примечание

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

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

9. При необходимости можно ввести описание резервного набора данных в текстовом поле Описание .

10. Укажите, когда истекает срок действия резервного набора данных.

    • Чтобы задать срок действия резервного набора данных, выберите пункт После (параметр по умолчанию) и введите срок действия набора в днях с момента его создания. Это значение может быть задано в диапазоне от 0 до 99 999 дней. Значение 0 означает, что срок действия резервного набора данных не ограничен.

      Значение по умолчанию задается в параметре Срок хранения носителей резервных копий по умолчанию (дней) диалогового окна Свойства сервера (страницаПараметры базы данных ). Для этого щелкните правой кнопкой мыши имя сервера в обозревателе объектов и выберите его свойства, затем страницу Параметры базы данных .

    • Чтобы указать дату истечения срока действия резервного набора данных, выберите пункт Наи введите дату истечения срока действия резервного набора данных.

11. Чтобы выбрать тип назначения резервной копии, выберите пункт Диск, URL-адрес или Лента. Чтобы выбрать пути к 64 (или менее) дискам или накопителям на магнитной ленте, содержащим один набор носителей, нажмите кнопку Добавить. Выбранные пути отображаются в списке Создать резервную копию в .

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

12. Чтобы просмотреть или выбрать дополнительные параметры, нажмите кнопку Параметры на панели Выбор страницы .

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

    • Создать резервную копию в существующем наборе носителей

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

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

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

      Если оставить имя носителя пустым и установить рядом с ним флажок для проверки, имя носителя при успешном завершении также станет пустым.

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

      Для этого параметра введите имя в текстовом поле Имя нового набора носителей и при необходимости введите описание набора носителей в текстовое поле Описание нового набора носителей . Дополнительные сведения см. в разделе Наборы носителей, семейства носителей и резервные наборы данных Sets (SQL Server).

14. В разделе Надежность можно установить следующие флажки.

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

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

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

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

16. При резервном копировании на накопитель на магнитной ленте (как указано в разделе Назначение страницы Общие) активен параметр Выгрузить ленту после резервного копирования. Щелкните этот параметр, чтобы активировать параметр Перемотать ленту перед выгрузкой .

17. SQL Server 2008 Enterprise и более поздние версии поддерживают сжатие резервных копий. По умолчанию сжатие резервных копий зависит от значения параметра конфигурации сервера backup-compression default . Однако независимо от текущего значения по умолчанию на уровне сервера можно сжать резервные копии, установив параметр Сжимать резервные копии, или отказаться от сжатия резервных копий, установив параметр Не сжимать резервные копии.

    Просмотр текущих значений параметров по умолчанию для сжатия резервных копий

Шифрование

Для шифрования файла резервной копии установите флажок Зашифровать файл резервной копии . Выберите алгоритм шифрования файла резервной копии и выберите сертификат или асимметричный ключ. Доступны следующие алгоритмы шифрования:

• AES 128

• AES 192

• AES 256

• Triple DES

Создание резервной копии журнала транзакций

1. Выполните инструкцию BACKUP LOG для создания резервной копии журнала транзакций, указав следующее:

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

   • Устройство резервного копирования, на которое записывается резервная копия журнала транзакций.

Пример (Transact-SQL)

 Важно

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

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

BACKUP LOG AdventureWorks2012 TO MyAdvWorks_FullRM_log1; GO

1. Используйте командлет Backup-SqlDatabase и укажите Log в качестве значения параметра -BackupAction.

   В следующем примере создается полная резервная копия журналов базы данных MyDB в заданном по умолчанию расположении резервного копирования на экземпляре сервера Computer\Instance.

   --Enter this command at the PowerShell command prompt, C:\PS> Backup-SqlDatabase -ServerInstance Computer\Instance -Database MyDB -BackupAction Log

Настройка и использование поставщика SQL Server PowerShell

BACKUP (Transact-SQL)Применение резервных копий журналов транзакций (SQL Server)Планы обслуживанияПолные резервные копии файлов (SQL Server)

msdn.microsoft.com

Настройка доставки журналов (SQL Server)

В данном разделе описывается настройка доставки журналов в SQL Server 2014 с помощью среды SQL Server Management Studio или Transact-SQL.

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

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

В области Выбор страницы щелкните Доставка журналов транзакций.

Установите флажок Включить эту базу данных в качестве источника в конфигурацию доставки журналов.

В разделе Резервные копии журналов транзакций нажмите кнопку Параметры копирования.

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

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

 Важно

Если учетная запись служб SQL Server на сервере-источнике выполняется с правами учетной записи «Локальная система», надо создать папку резервного копирования на сервере-источнике и указать локальный путь к ней.

Настройте параметры Удалить файлы, созданные ранее и Предупредить, если резервное копирование не произошло в течение.

Обратите внимание на расписание в поле Расписание в разделе Задание резервного копирования. Если нужно изменить расписание, нажмите кнопку Расписание и задайте расписание для агента SQL Server по своему усмотрению.

SQL Server 2014 поддерживает сжатие резервных копий. При создании конфигурации доставки журналов можно управлять поведением сжатия резервных копий журналов, выбрав один из следующих параметров: Использовать параметр сервера по умолчанию, Сжимать резервные копии или Не сжимать резервные копии. Дополнительные сведения см. в статье Настройки резервного копирования журналов транзакций для доставки журналов.

Нажмите кнопку ОК.

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

Нажмите Соединить и соединитесь с экземпляром SQL Server, который нужно использовать в качестве сервера-получателя.

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

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

 Примечание

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

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

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

На вкладке Восстановление журнала транзакций в разделе Состояние базы данных во время восстановления резервных копий выберите пункт Без режима восстановления или Режим ожидания.

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

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

Выберите пороговое значение для предупреждения в поле Предупреждение, если восстановление не выполнено в течение.

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

Нажмите кнопку ОК.

В разделе Экземпляр сервера мониторинга выберите флажок Использовать экземпляр сервера мониторинга и затем нажмите кнопку Настройки.

 Важно

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

Нажмите кнопку Соединить и соединитесь с экземпляром компонента SQL Server, который нужно использовать в качестве сервера мониторинга.

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

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

Нажмите кнопку ОК.

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

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

Для добавления базы данных-источника на сервер-источник выполните процедуру sp_add_log_shipping_secondary_database. Хранимая процедура возвращает идентификатор задания резервирования и первичный идентификатор.

Для установки расписания заданий копирования и восстановления выполните процедуру sp_add_jobschedule на сервере-источнике.

Для добавления задания предупреждения выполните процедуру sp_add_log_shipping_secondary_database на сервере мониторинга.

Включите задание копирования на сервере-источнике.

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

На сервере-получателе выполните процедуру sp_add_jobschedule для настройки расписания заданий копирования и восстановления.

На сервере-получателе выполните процедуру sp_add_log_shipping_secondary_database для добавления базы данных-получателя.

На сервере-источнике выполните процедуру sp_add_log_shipping_primary_secondary для добавления на сервер-источник необходимых сведений о новой базе данных-получателе.

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

msdn.microsoft.com

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

Эта документация перемещена в архив и не поддерживается.

SQL Server 2012

При обновлении с 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. Обновление экземпляра сервера-источника с отработкой отказа

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

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

Важно!

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

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

Процедура 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

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

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

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).

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

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

msdn.microsoft.com

---

Смотрите также

• 
  Стрижка журнал оракул
• 
  Журнал управление предприятием
• 
  Журнал авансовых отчетов
• 
  Социальная психология журналы
• 
  Обои из журналов
• 
  Журнал томский вестник
• 
  Журнал производственной практики
• 
  Плетение из журналов
• 
  Журнал событий сервера
• 
  21 гимназия журнал
• 
  Управление предприятием журнал