Планирование последовательности поэтапного восстановления для файлов в состоянии ожидания восстановления, состоянии восстановления или в автономном состоянии
Сведения в этом разделе относятся только к тем базам данных SQL Server, которые содержат несколько файловых групп (для простой модели восстановления — файловые группы только для чтения) при планировании поэтапного восстановления базы данных.
Если последовательность восстановления содержит файл, находящийся в состоянии восстановления, ожидания восстановления или в автономном состоянии, то можно восстановить этот файл без восстановления его данных. Чтобы определить, необходимо ли восстановление полной резервной копии или можно просто восстановить отдельный файл, воспользуйтесь метаданными, хранящимися в представлениях каталога sys.database_files и sys.master_files.
Номера LSN повтора
Вначале необходимо просмотреть столбцы представления каталога, которые содержат номера LSN повтора: redo_start_lsn, redo_start_fork_guid, redo_target_lsn и redo_target_fork_guid. Следующая таблица описывает номера LSN повтора и их назначение.
Столбцы |
Описание |
---|---|
redo_start_lsn и redo_start_fork_guid |
Вместе эти столбцы описывают пару (lsn, guid), которая представляет момент времени файла. При накате файла значения этих столбцов изменяются. Накат продолжается с этой точки.
Важно!
Если redo_start_lsn= NULL, то состояние файла на диске неизвестно, и его необходимо восстановить из полной резервной копии.
|
redo_target_lsn и redo_target_fork_guid |
Вместе эти столбцы описывают пару (lsn, guid), определяющую точку восстановления, до которой следует восстановить файл, чтобы он был согласован с оперативной базой данных (целевой точкой восстановления). |
Принятие решения об использовании sys.database_files или sys.master_files
Представления каталога sys.database_files и sys.master_files содержат столбцы номеров LSN повтора, однако эти представления не всегда являются согласованными. Как правило, если база данных работает в оперативном режиме, то значения в sys.database_files и sys.master_files согласованы между собой. Они могут быть не согласованы между собой в следующих случаях.
Если база данных только для чтения, любые изменения, вызванные резервной копией, не приводят к обновлению столбца sys.database_files. Обновленные сведения о файлах содержат только столбец sys.master_files.
Примечание Чтобы определить, доступен ли файл только для чтения, просмотрите столбцы is_read_only и read_only_lsn. Эти сведения содержат столбец is_read_only. Если да, то read_only_lsn — момент, где файл стал доступным только для чтения.
Если база данных работает в автономном режиме (например во время восстановления), то каталог базы данных недоступен. Сведения об автономной базе данных следует получать с помощью sys.master_files.
Если операция восстановления в текущий момент затрагивает файл, то номера LSN повторов этого файла обновляются и становятся несогласованными. Столбцы номеров LSN повтора следует просматривать только между операциями восстановления.
Интерпретация столбцов метаданных
Примечание |
---|
Материал данного раздела предполагает, что читатель знаком с понятиями «путь восстановления» и «вилка восстановления». Дополнительные сведения см. в разделе Пути восстановления. |
С содержанием этого раздела следует знакомиться только при выполнении восстановления на момент времени и при наличии остающихся резервных копий из какого-либо уничтоженного пути восстановления. При восстановлении файла, находящегося в состоянии восстановления, ожидания восстановления или в автономном состоянии, существенную роль играют вилки восстановления. Проанализировав вилки восстановления, можно выявить потенциальные пути восстановления. Как правило, в случае при восстановлении базы данных наилучшим будет являться только один путь восстановления.
Чтобы его выявить, необходимо выяснить, на какой вилке восстановления расположен файл: на целевой или на какой-либо другой.
Файл относится к иной вилке восстановления.
Если redo_start_fork_guid!=redo_target_fork_guid и не является предком redo_target_fork_guid, то файл находится в вилке восстановления, отличной от целевой.
Примечание Чтобы найти вилку-предок, пройдите по цепочке журналов назад. Дополнительные сведения см. в разделе Пути восстановления.
В этом случае файл нужно восстанавливать из полной резервной копии. При этом файл будет перемещен в момент времени, который будет действительным предком текущей точки восстановления базы данных.
Примечание Для восстановления какого-либо файла его резервная копия должна быть предком точки восстановления базы данных. Всегда следует искать последнюю полную резервную копию файлов. Данные следует накатить до целевой точки. Единственное исключение — резервная копия файлов только для чтения, для которой не нужен накат, если файл был доступен только для чтения еще до резервного копирования. Если необходимо, то после восстановления резервной копии файлов восстановите разностную резервную копию файлов (если есть) и резервные копии журналов для перевода этого файла в целевую точку восстановления.
Файл относится к текущей (целевой) вилке восстановления или является ее предком.
Примечание Если резервное копирование файла выполнялось с момента восстановления базы данных, то файл находится в целевой вилке восстановления.
В таких случаях необходимость восстановления файла зависит от связи между redo_start_lsn и redo_target_lsn. Это описано в следующей таблице.
Если...
То...
redo_start_lsn=redo_target_lsn
Восстановление файла не требуется.
Файл согласован с базой данных и может быть переключен в оперативный режим без использования RESTORE DATABASE database_name WITH RECOVERY.
redo_start_lsn<redo_target_lsn
Прежде чем файл можно будет переключить в оперативный режим, накат должен достичь redo_target_lsn.
redo_start_lsn>redo_target_lsn
База данных старше файла. Файл следует восстановить из полной резервной копии (или базу данных можно повторно восстановить до более позднего момента времени с помощью другой последовательности частичного восстановления).
ПримечаниеТакая ситуация может сложиться только при автономном восстановлении, поскольку как только будет восстановлена первичная файловая группа, создается новая вилка восстановления. Любые невосстановленные вторичные файловые группы уже не будут относиться к тому же пути восстановления, что и первичная файловая группа.
Примечание |
---|
После того как произведено восстановление резервной копии по одному из этих путей восстановления, другие пути восстановления становятся недействительными. Резервные копии, которые соответствуют недействительным путям восстановления, становятся уничтоженными. Лучшим выходом будет удалить их или перенести их в другое место, пометив как уничтоженные. |
См. также