Модели транзакций Журнализация и буферизация

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

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

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

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

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

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

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

Алгоритм отката транзакции 1. Выбирается очередная запись из списка данной транзакции 2. Выполняется противоположная по смыслу операция: (вместо операции INSERT выполняется соответствующая операция DELETE, вместо операции DELETE выполняется INSERT и вместо прямой операции UPDATE обратная операция UPDATE 3. Любая из этих обратных операций также заносится в журнал. 4. При успешном завершении отката в журнал заносится запись о конце транзакции.

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

Будем считать, что в журнале отмечаются точки физической согласованности базы данных моменты времени, в которые во внешней памяти содержатся согласованные результаты операций, завершившихся до соответствующего момента времени, и отсутствуют результаты операций, которые не завершились, а буфер журнала вытолкнут во внешнюю память. Назовем такие точки tpc (time of physical consistency) точками физического согласования.

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

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

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

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

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

транзакция успешно завершена Для транзакции Т1 никаких действий производить не требуется. Она закончилась до момента tpc, и все ее результаты отражены во внешней памяти базы данных.

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

транзакция получила и выполнила команду отката ROLLBACK Для транзакции ТЗ нужно выполнить в обратном направлении первую часть операций (undo). Во внешней памяти базы данных полностью отсутствуют результаты операций ТЗ, которые были выполнены после момента tpc. С другой стороны, во внешней памяти гарантированно присутствуют результаты операций ТЗ, которые были выполнены до момента tpc. Следовательно, обратная интерпретация операций ТЗ корректна и приведет к согласованному состоянию базы данных (поскольку транзакция ТЗ не завершилась к моменту мягкого сбоя, при восстановлении необходимо устранить все последствия ее выполнения).

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

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

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

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

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