Восстановление

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

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

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

Итак, все сведения о выполненных действиях СУБД вносит в журнал, причем в журнале хранятся и данные об исходном состоянии записей. Именно эти данные используются в случае отмены транзакции для восстановления исходного состояния базы данных. При этом гарантируется, что на момент завершения операции COMMIT сведения о фиксируемой транзакции внесены в журнал. Это так называемое «правило опережающей записи в журнал». Фактическое обновление данных в таблицах может быть отложено – выгоднее выполнять одну крупную операцию записи на диск, а не множество мелких, так что данные могут какое-то время находиться в оперативной памяти.

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

В случае возникновения отказа системы тяжесть последствий зависит от того, какой именно отказ произошел. Можно выделить две категории отказов:

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

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

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

Рассмотрим в общих чертах процесс заполнения журнала и восстановления базы данных по нему после сбоя.

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

Время

ts

tf

T1

T2

T3

T4

T5

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

Рисунок …. Пример последовательности транзакций.

На рисунке вверху показана шкала времени, ts – момент установки контрольной точки, tf – момент сбоя. T1 … T5 – транзакции, при этом транзакции T1, T2 и T4 успели завершиться, а T3 и T5 все еще выполнялись на момент сбоя.

В процессе восстановления просматривается журнал транзакций с последней контрольной точки (или с момента создания резервной копии). Соответственно, транзакция Т1 вообще не будет участвовать в процедуре восстановления, так как она уже полностью записана в файлах базы данных.

При нахождении в журнале команды начала транзакции такая транзакция записывается в список UNDO (список отмены).

При нахождении команды COMMIT транзакция, к которой команда относится, переносится в список REDO (список повтора).

При нахождении команды ROLLBACK транзакция вообще исключается из рассмотрения – очевидно, что для отмененных транзакций нет необходимости вносить какие-либо изменения в файлы базы данных.

После достижения конца журнала транзакции из списка UNDO откатываются, а транзакции из списка REDO выполняются повторно. Порядок выполнения этих действий может быть разным, но после обработки списков состояние базы данных будет восстановлено на момент сбоя. Транзакции, которые не были завершены на момент сбоя, будут потеряны, но их можно запустить повторно.

Таким образом, видно, что транзакции являются единицами восстановления данных после сбоев.