Резервное копирование и восстановление


Резервное копирование и восстановление можно выполнить с помощью утилит (например, Enterprise Manager в MS SQL Server), мастера или команд T-SQL. Для размещения архивных копий должно быть создано логическое устройство (которое может быть отдельным физическим устройством).

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

Полное резервное копирование обеспечивает архивирование всех данных базы, размещенных как в группах файлов, так и в отдельных файлах. Этот способ наиболее часто используется для архивирования БД небольшого размера. В других случаях надо использовать выборочное копирование или копирование групп файлов.

Выборочное (дифференциальное) резервное копирование обеспечивает архивирование только тех данных базы, которые были изменены с момента последнего архивирования.

Резервное копирование журнала транзакций обеспечивает архивирование и усечение журнала.

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

Восстановление БД после сбоев обеспечивается с помощью журнала транзакций. Основным принципом согласованной политики записи изменений в журнал и в БД является то, что запись об изменении объекта БД должна попадать во внешнюю память журнала раньше, чем измененный объект оказывается во внешней памяти БД. Протокол журнализации (и управления буферизацией) называется WAL (Write Ahead Log – «пиши сначала в журнал»).

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

Иногда для восстановления БД после сбоя журнала изменений недостаточно. Основой восстановления в этом случае являются журнал и архивная копия БД. Восстановление начинается с обратного копирования БД из архивной копии. Затем для всех закончившихся транзакций по журналу повторно выполняются все операции. Для транзакций, не закончившихся к моменту сбоя, выполняется откат.

К ведению журнала предъявляются особые требования по части надежности, однако реально возможна и его утрата. Тогда единственным способом восстановления БД является возврат к архивной копии. Самый простой способ производства архивных копий БД – архивировать БД при переполнении журнала. В этом случае образование новых транзакций временно блокируется. Когда БД придет в согласованное состояние, можно выполнять ее архивацию, после чего начинать заполнять журнал заново. Можно выполнять архивацию БД реже, чем переполняется журнал. При переполнении журнала и окончании начатых транзакций можно архивировать сам журнал. Поскольку архивированный журнал требуется только для воссоздания архивной копии БД, журнальная информация при архивации может быть сжата.

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

Существуют общие требования к системе восстановления данных в СУБД.

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

2. Быстрое восстановление данных обеспечивается генерацией данных, используемых для восстановления.

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

Для восстановления БД в составе СУБД имеются следующие средства:

· программы ведения системного журнала регистрируют операции над БД;

· программы архивации используются для регулярного получения копий БД для последующего ее восстановления;

· программы восстановления применяются для возврата БД или некоторых ее частей в состояние, предшествующее возникновению отказа;

· программы отката ликвидируют последствия выполнения определенной транзакции в БД;

· программы записи контрольных точек и повторного исполнения позволяют ускорить восстановление.

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

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

· запись на диск всех страниц, измененных к началу контрольной точки;

· запись в журнал транзакций списка незавершенных транзакций;

· запись в журнал транзакций всех измененных страниц;

· регистрация завершения контрольной точки в базе данных (а не в журнале транзакций).



Дата добавления: 2017-10-04; просмотров: 1706;


Поиск по сайту:

Воспользовавшись поиском можно найти нужную информацию на сайте.

Поделитесь с друзьями:

Считаете данную информацию полезной, тогда расскажите друзьям в соц. сетях.
Poznayka.org - Познайка.Орг - 2016-2024 год. Материал предоставляется для ознакомительных и учебных целей.
Генерация страницы за: 0.007 сек.