Резервное копирование в полной модели восстановления

Изменения: 17 июля 2006 г.

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

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

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

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

На следующем рисунке показана наиболее простая стратегия резервного копирования при полной модели восстановления. Он иллюстрирует создание резервной копии базы данных Db_1 и двух плановых резервных копий журнала — Log_1 и Log_2. Через некоторое время после создания резервной копии журнала Log_2 в базе данных происходит потеря данных. Перед восстановлением из этих трех резервных копий администратор базы данных должен создать резервную копию активного журнала (заключительного фрагмента журнала). Затем он восстанавливает Db_1, Log_1 и Log_2 без восстановления базы данных, а после этого копирует и восстанавливает резервную копию заключительного фрагмента журнала. Тем самым производится восстановление базы данных до точки сбоя с полным восстановлением всех данных.

Минимизация потерь данных

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

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

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

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

До создания первой резервной копии (см. рисунок) существовала вероятность потери данных (с момента t0 до t1). Регулярное резервное копирование журнала уменьшает риск потери данных, поскольку могут быть потеряны только те изменения, которые произошли после последнего резервного копирования журнала (t14 на данном рисунке). При возникновении сбоя администратор базы данных должен попытаться создать резервную копию активной части (заключительного фрагмента) журнала. Если резервное копирование заключительного фрагмента журнала будет выполнено успешно, базу данных удастся восстановить до момента возникновения сбоя.

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

Благодаря протоколированию всех операций, в том числе массовых операций (SELECT INTO, CREATE INDEX и массовой загрузки данных), полная модель восстановления позволяет восстановить базу данных до точки сбоя или другого, более раннего момента времени (этот процесс называется восстановлением на момент времени).

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

Примечание.

В SQL Server 2000 и более поздних версиях использование параметра базы данных select into/bulkcopy процедуры sp_dboption вновь переключает базу данных на модель с неполным протоколированием (BULK_LOGGED). В SQL Server 2000 этот параметр необходим для создания постоянной таблицы при помощи инструкции SELECT INTO. В SQL Server 2005 этот параметр необязателен и его применения следует избегать. Вместо него следует пользоваться инструкцией ALTER DATABASE. Хранимая процедура sp_dboption в следующих версиях SQL Server будет удалена.

Использование резервных копий для восстановления базы данных

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

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

Примечание.

Если база данных находится в оперативном состоянии, то при использовании полной модели восстановления или модели восстановления с неполным протоколированием SQL Server 2005 Enterprise Edition поддерживает восстановление файлов и страниц. Этот процесс называется оперативным восстановлением. Синтаксис инструкции RESTORE для восстановления файлов или страниц при автономном и оперативном состояниях базы данных одинаков.

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

См. также

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

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

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

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

Справка и поддержка

Получение помощи по SQL Server 2005

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