Главная » Microsoft SQL Server, Базы данных » Модели восстановления

0

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

Таблица 36.1. в SQL Server

Модель

восста

новления

Описание

Атомар

ность

транзакций

Живучесть транзакций

Массовые операции

(SELECT INTO И BULK INSERT)

Простая

Журнал транзакций постепенно обрезается в контрольных точках

Да

Нет. Можно восстановить только последнюю полную или дифференцированную резервную копию

Не протоколируются с целью повышения производительности

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

Инструкции SELECT INTO И BULK

insert не протоколируются как транзакции

Да

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

Только отмеченные (с целью повышения производительности)

Модель

восста

новления

Описание

Атомар

ность

транзакций

Живучесть транзакций

Массовые операции (SELECT INTO И BULK INSERT)

 

Полная

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

Да

Да. Можно к любой точке

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

 

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

Простая модель восстановления

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

Так как журнал транзакций в этой модели является только временным местом хранения, отпадает потребность в его резервировании. Эта модель восстановления имеет ряд преимуществ. Во-первых, журнал транзакций имеет маленькие размеры, однако расплачиваться за это придется потерей всех транзакций, выполненных с момента последнего полного или дифференцированного резервирования. Выбор простоя модели восстановления функционально эквивалентен установке в версиях SQL Server 7.0 и более поздних параметра базы данных truncate log on checkpoints в значение true.

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

Рис. 36.1. Типичный план восстановления, использующий простую модель, содержит только полные и дифференцированные копии резервирования

Восстановление в простой модели предполагает две операции.

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

2.              Восстановление из последней (не обязательно) одной дифференцированной резервной копии.

Полная модель восстановления

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

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

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

?               Массовые операции будут выполняться значительно медленнее. Если база данных не импортирует информацию с использованием массовых методов, то данный вопрос следует обсудить отдельно.

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

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

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

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

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

1.              Резервирование текущего журнала транзакций.

V               Если повреждена дисковая подсистема, содержащая журнал транзакций, то ба-

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

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

3.              Выполните восстановление из последней дифференцированной резервной копии, созданной после выполнения последнего полного резервирования (если таковая имеется).

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

Рис. 36.2. Типичный план восстановления, использующий полную модель, содержит полные, дифференцированные и транзакционные резервные копии

Форма восстановления утилиты Management Studio (на ней мы остановимся немного позже) автоматически поможет вам выбрать корректный набор резервных копий, так что ваша задача на практике окажется не такой сложной, какой кажется на первый взгляд.

Модель с неполным протоколированием

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

?               массовые вставки (с использованием утилиты ВСР);

?               инструкции DML SELECT * INTO;

?               операции над особо крупными объектами WRITETEXT и UPDATETEXT;

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

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

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

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

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

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

Использование этой модели аналогично установке параметра базы данных Select Into/ Bulkcopy в значение true.

Установка модели восстановления

Модель восстановления, установленная в системной базе model, применяется ко всем создаваемым базам данных. Установка модели восстановления выполняется во вкладке Options диалогового окна Database Properties утилиты Management Studio. Чтобы открыть это окно, щелкните правой кнопкой мыши на базе данных и выберите в контекстном меню пункт Properties.

Модель восстановления можно изменить и программным путем; для этого используется инструкция DDL ALTER DATABASE:

ALTER DATABASE имя_ б а зы_да нных SET Recovery параметр;

Допустимыми параметрами в этой инструкции являются следующие: Full, Bulk-Logged и Simple. В следующем примере модель восстановления учебной базы данных СНА2 изменяется на полную:

USE СНА2;

ALTER DATABASE СНА2 SET Recovery Full;

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

Текущую модель восстановления, установленную в базе данных, можно определить с помощью представления каталога sys .Database:

SELECT [name], recovery_model_desc FROM sysdatabases;

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

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

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

Во время восстановления берутся в расчет существующие полные, дифференцированные и транзакционные резервные копии — систему совершенно не волнует, как именно они создавались.

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

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

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

Источник: Нильсен, Пол. Microsoft SQL Server 2005. Библия пользователя. : Пер. с англ. — М. : ООО “И.Д. Вильямс”, 2008. — 1232 с. : ил. — Парал. тит. англ.

По теме:

  • Комментарии