Пути восстановления

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

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

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

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

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

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

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

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

Примеры пути восстановления

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

Резервная копия базы данных и первые четыре резервные копии журналов расположены в ветке 1. Пятая и шестая резервные копии журналов расположены в ветке 2. Вилка восстановления содержит последний номер LSN второй резервной копии журнала (Log_Backup_2.LastLSN) и первый номер LSN пятой резервной копии журнала (Log_Backup_5.FirstLSN).

Внутри пятой резервной копии журнала first_recovery_fork_guid идентифицирует ветку 1, а last_recovery_fork_guid — ветку 2. Путь восстановления — это ветка 1 и ветка 2.

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

Восстановление и накат вдоль старого пути

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

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

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

Восстановление и накат от старого пути до нового

Компонент SQL Server Database Engine предотвращает использование в одной последовательности восстановления нескольких резервных копий, накат в которых происходит по различным путям восстановления. Это ограничение обеспечивает согласованность базы данных после восстановления.

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

1. Восстановите резервные копии, которые были созданы до восстановления, соответствующего новому пути восстановления. Исключите резервную копию, которая содержит точку восстановления.
2. Произведите накат по новому пути восстановления, восстановив резервные копии, созданные с момента создания пути восстановления.

Например, рассматривая резервные копии, созданные в предыдущем примере, предположим, что третья резервная копия журнала охватывает период времени от 10:00 до 11:00. В этот период происходит восстановление на момент времени, которое задается предложением STOPAT**=10:**30. При этом создается вилка и начинается новая ветка восстановления. Ветка 2. Новая резервная копия журнала на новой ветке (пятая резервная копия журнала) содержит тот же номер LSN, что и третья резервная копия журнала, и заменяет ее, поскольку теперь она является нефункционирующей. Чтобы восстановить резервные копии по новому пути (начиная от ветки 1 и заканчивая веткой 2), воспользуйтесь следующей последовательностью восстановления: полная резервная копия базы данных, резервная копия журнала 1, резервная копия журнала 2, резервная копия журнала 5 и резервная копия журнала 6.

Управление разветвлениями восстановления

Ветвь восстановления является диапазоном номеров LSN, для которых установлен одинаковый идентификатор GUID. Путь восстановления описывает диапазон номеров LSN от точки запуска (LSN,GUID) до конечной точки (LSN,GUID). Диапазон номеров LSN в пути восстановления может пересекать одну или более ветвей от начала до конца. Новая ветвь восстановления возникает при создании базы данных, а также если инструкция RESTORE WITH RECOVERY формирует вилку восстановления.

Разветвление восстановления является точкой (LSN,GUID), на которой новая ветвь восстановления запускается каждый раз, когда выполняется инструкция RESTORE WITH RECOVERY. Каждое разветвление восстановления определяет связь типа родители-потомки между ветвями восстановления.

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

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

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

• Для каждой восстанавливаемой резервной копии журнала в последовательности идентификатор first_recovery_fork_guid должен быть равен идентификатору last_recovery_fork_guid предыдущей резервной копии в последовательности.
  
• Резервные копии данных и разностные резервные копии также должны быть связаны.
  Если в резервной копии журналов одновременно содержатся и вилка, и последний номер LSN полной резервной копии или разностной резервной копии, то проверка связи зависит от местоположения последнего номера LSN относительно вилки.
  Проверка связи выполняется, как описано ниже, при использовании значений из таблицы backupset.
  • Если номер last_lsn меньше или равен fork_point_lsn, то идентификатор last_recovery_fork_guid резервной копии данных или разностной резервной копии должен быть равен first_recovery_fork_guid резервной копии журналов. На следующем рисунке показана ситуация, где last_lsn меньше fork_point_lsn.
    
  • Если номер last_lsn больше fork_point_lsn, то идентификатор last_recovery_fork_guid резервной копии данных или разностной резервной копии должен быть равен last_recovery_fork_guid резервной копии журналов. На следующем рисунке показана ситуация, когда last_lsn больше fork_point_lsn.
    
• Для разностной резервной копии найдите основу через backupset.differential_base_guid.
  Если разностная резервная копия является многобазовой, то значение backupset.differential_base_guid равно NULL, а основы для разностной копии для каждого из файлов необходимо определить через backupfile.differential_base_guid.

См. также

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

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

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

Реализация сценариев восстановления для баз данных SQL Server

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

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