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

Восстановление БД – это процесс возвращения БД в корректное состояние, утраченное в результате сбоя или отказа системы.

Причины отказов:

1 Аварийное прекращение работы системы, вызванное ошибкой оборудования или программного обеспечения, приведшей к разрушению оперативной памяти.

2 Отказ носителей информации.

3 Ошибки прикладных программ – например, логические ошибки в программах, получающих доступ к БД, послужившие причиной сбоев при выполнении некоторых транзакций.

4 Стихийные бедствия.

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

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

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

Типичная СУБД должна иметь следующие функции восстановления:

*Типичная – не значит любая, могут быть СУБД без этих функций или реализовывать их не в полном объеме. */

1 Механизм резервного копирования (backup,dump). Этот механизм позволяет создавать резервные копии БД и ее журнала без необходимости останавливать систему. /*Если есть возможность остановить систему или нет нужного механизма, то можно просто копировать необходимые файлы. */ Резервная копия используется в случае повреждения физического носителя. В этом случае БД восстанавливается (restore) с резервной копии в том состоянии, в котором находилась на момент создания копии, то есть все изменения, произошедшие после, будут потеряны. Резервное копирование может выполняться для БД в целом или в инкрементном режиме. В последнем случае в копию помещаются изменения, произошедшие в БД со времени последнего резервного копирования. Существует возможность создавать резервные копии не целой БД, а отдельных таблиц.

2 Журнал (log). Журнал – отдельный файл, который содержит информацию о ходе выполнения транзакций в БД. Для каждой операции, выполненной в БД, журнал может содержать следующую информацию:

а) идентификатор транзакции;

б) тип записи: начало транзакции, операция вставки, удаления, модификации, отмена транзакции или ее фиксация;

в) идентификатор элемента данных, вовлеченного в операцию;

г) копию элемента данных до начала операции

д) копию элемента данных после окончания операции

е) служебную информацию, например, указатели на следующую и предыдущую операции этой транзакции.

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

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

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