Восстановление на основе журнала в СУБД

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

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

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

Запись журнала обновлений, представленная как: <Ti, Xj, V1, V2>, имеет следующие поля:

1. Идентификатор транзакции: уникальный идентификатор транзакции, которая выполнила операцию записи.
2. Элемент данных: Уникальный идентификатор записанного элемента данных.
3. Старое значение: значение элемента данных до записи.
4. Новое значение: значение элемента данных после операции записи.

Другой тип записей журнала:

1. <Ti start> : содержит информацию о том, когда начинается транзакция Ti.
2. <Ti commit> : содержит информацию о том, когда транзакция Ti фиксируется.
3. <Ti abort> : содержит информацию о том, когда транзакция Ti прерывается.

Отменить и повторить операции -
Поскольку всем модификациям базы данных должно предшествовать создание записи журнала, в системе доступно как старое значение до модификации элемента данных, так и новое значение, которое должно быть записано для элемента данных. Это позволяет системе при необходимости выполнять операции повтора и отмены:

1. Отменить: использование записи журнала устанавливает для элемента данных, указанного в записи журнала, старое значение.
2. Повторить: использование записи журнала устанавливает для элемента данных, указанного в записи журнала, новое значение.

База данных может быть изменена с использованием двух подходов -

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

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

1. Транзакцию Ti необходимо отменить, если журнал содержит запись <Ti start>, но не содержит ни записи <Ti commit>, ни записи <Ti abort>.
2. Транзакцию Ti необходимо повторить, если журнал содержит запись <Ti start> и либо запись <Ti commit>, либо запись <Ti abort>.

Использование контрольно-пропускных пунктов -
Когда происходит сбой системы, пользователь должен просмотреть журнал. В принципе, для определения этой информации необходимо поискать во всем журнале. Этот подход сопряжен с двумя основными трудностями:

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

Чтобы уменьшить эти типы накладных расходов, пользователь вводит контрольные точки. Запись журнала в форме <контрольная точка L> используется для представления контрольной точки в журнале, где L - это список транзакций, активных во время контрольной точки. Когда запись журнала контрольной точки добавляется в журнал, все транзакции, которые были зафиксированы до этой контрольной точки, имеют запись журнала <Ti commit> перед записью контрольной точки. Любые модификации базы данных, сделанные Ti, записываются в базу данных либо до контрольной точки, либо как часть самой контрольной точки. Таким образом, во время восстановления нет необходимости выполнять операцию повтора на Ti.

После того, как произошел сбой системы, система проверяет журнал, чтобы найти последнюю запись <контрольная точка L>. Операции повтора или отмены должны применяться только к транзакциям в L и ко всем транзакциям, которые начали выполнение после того, как запись была записана в журнал. Обозначим этот набор транзакций как T. Те же правила отмены и повтора применимы к T, как указано в разделе Восстановление с использованием записей журнала.

Обратите внимание, что пользователю необходимо изучить только ту часть журнала, которая начинается с последней записи журнала контрольной точки, чтобы найти набор транзакций T и выяснить, происходит ли в журнале запись фиксации или отмены для каждой транзакции в T. Например, рассмотрим множество транзакций {T0, T1,. . ., Т100}. Предположим, что самая последняя контрольная точка имела место во время выполнения транзакции T67 и T69, а T68 и все транзакции с индексами ниже 67 завершились до контрольной точки. Таким образом, только транзакции T67, T69,. . ., T100 нужно учитывать при схеме восстановления. Каждую из них необходимо переделать, если она завершена (то есть зафиксирована или прервана); в противном случае он был неполным и его необходимо отменить.