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

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

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

• Таблица backupset в msdb. Названиями столбцов являются first_lsn и last_lsn.
• Инструкция RESTORE HEADERONLY. Столбцы называются FirstLSN и LastLSN.

Следующие таблицы определяют эти данные для различных резервных копий.

Термин	Определение
first_lsn или FirstLSN	Регистрационный номер транзакции в журнале первой или самой ранней записи журнала в резервном наборе данных. Для данных или разностных резервных копий первый номер LSN определяет самую раннюю запись журнала, необходимую для выполнения восстановления с данной резервной копии. Для резервных копий журналов первый номер LSN определяет первую запись журнала, включенную в данную резервную копию.
last_lsn или LastLSN	Регистрационный номер транзакции в журнале записи, следующей за резервным набором данных. Последний номер LSN обозначает запись журнала, следующую за концом резервной копии. Для данных и разностных резервных копий (и резервных копий журналов, содержащих операции с неполным протоколированием), накат должен производиться как минимум до этого номера LSN. В противном случае данные, копируемые при восстановлении, не будут согласованными. Для резервных копий журналов соответствующая резервная копия включает записи журналов до данного LSN, но не включая его самого.

LSN номера и резервные копии данных или разностные резервные копии

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

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

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

LSN номера и резервные копии журналов в цепочке журналов

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

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

В резервных копиях журналов номер first_lsn — это номер LSN первой записи журнала в данной резервной копии, и, начиная с этой записи, резервная копия журнала включает записи журналов до записи с номером LSN, равным last_lsn, но не включая ее. Две резервные копии журнала являются последовательными тогда и только тогда, когда номер LSN последней записи журнала в более ранней копии (Backup_A) больше или равен номеру LSN первой записи журнала в последующей резервной копии (Backup_B); то есть Backup_A.last_lsn>= Backup_B.first_lsn. Если это не так, то между этими резервными копиями есть пропуск.

Смысл связи между этими номерами LSN следующий.

• A.last_lsn= B.first_lsn
  Если A.last_lsn= B.first_lsn, B обычно является резервной копией журналов, снятой сразу же после A.
  Эта связь показана на следующем рисунке. Обратите внимание, что запись журнала n, присутствующая в резервной копии журналов B, была записана под номером last_lsn в резервной копии журналов A и под номером first_lsn в резервной копии журналов B.
  
• A.last_lsn> B.first_lsn
  Если A.last_lsn> B.first_lsn, имеет место перекрытие. Перекрытие обычно возникает из-за создания резервной копии журналов только для копирования или создания первой резервной копии журналов после восстановления на данный момент времени. Перекрытие может приводить к различным вилкам восстановления. Дополнительные сведения см. в разделе Пути восстановления.

Причины разорванных цепочек журналов

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

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

См. также

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

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

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

backupset (Transact-SQL)
Инструкция RESTORE HEADERONLY (Transact-SQL)

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

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