Статья
04/01/2012

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

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

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

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

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

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

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

Восстановление базы данных по модели полного восстановления

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

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

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

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

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

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

Сведения о разностных резервных копиях см. в разделе Использование разностного резервного копирования.

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

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

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

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

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

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

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

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

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

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

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