5.5 Обеспечение атомарности и долговременности

Вернемся к свойствам атомарности и долговременности транзакций. Если первое из них должно быть интуитивно понятно, то второе, возможно, требует пояснений. Почему сохранение результата выполнения транзакций требует гарантий? Дело в том, что в современные СУБД широко используют "отложенную запись". Данные, записанные приложением в базу данных, могут на самом деле сохраняться в буферах в оперативной памяти и записываться на внешнюю память лишь некоторое время спустя. Это дает СУБД возможность уменьшить число физических операций ввода-вывода. Если между фиксацией транзакции в приложении и реальной записью данных на внешнюю память произойдет сбой, то данные, которые приложение считает уже зафиксированными, будут потеряны. Для выполнения операции отката при неуспешном выполнении транзакции или для восстановления данных после сбоя системы используется журнал транзакций. Журнал транзакций содержит детали всех операций модификации данных в базе данных, в частности, старое и новое значение модифицированного объекта, системный номер транзакции, модифицировавшей объект, и другую информацию.

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

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

На рис. 5.6 показаны варианты транзакций, подлежащих восстановлению, если фиксация контрольной точки произошла в момент времени tc, а сбой системы - в момент tf.

Рисунок 5.6 - Варианты транзакций, подлежащих восстановлению

На рис.5.6. представлены следующие варианты состояния транзакций на момент сбоя:

• T1 - транзакция успешно завершена до фиксации контрольной точки;
• T2 - транзакция начата до фиксации контрольной точки и успешно завершена после контрольной точки, но до наступления сбоя;
• T3 - транзакция начата до фиксации контрольной точки и не завершена в результате сбоя;
• T4 - транзакция начата после фиксации контрольной точки и успешно завершена до сбоя;
• T5 - транзакция начата после принятия контрольной точки и не завершена в результате сбоя.

Когда СУБД приступает к восстановлению после сбоя, журнал транзакций на внешней памяти содержит:

• все записи о выполнении транзакций T1, T2 и T4, включая записи об их фиксации;
• записи об операциях, выполненных транзакцией T3 до фиксации контрольной точки.

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

На внешнюю память записаны следующие изменения в данных:

• все изменения, выполненные транзакцией T1;
• часть изменений, выполненных транзакциями T2 и T3 до фиксации контрольной точки.

На внешнюю память не записаны никакие изменения, выполненные транзакциями T4 и T5.

Восстанавливая состояние базы данных, СУБД выполняет следующую последовательность действий:

1. Создаются два списка транзакций. В список UNDO (отменить) заносятся все транзакции, выполнявшиеся в момент фиксации контрольной точки. Список REDO (повторить) создается пустым. В нашем примере: UNDO = {T2, T3}, REDO = { }.
2. Журнал транзакций просматривается вперед, начиная от записи последней контрольной точки. Если в журнале обнаруживается запись о начале транзакции, то эта транзакция добавляется в список UNDO. В Если в журнале обнаруживается запись об окончании транзакции, то эта транзакция добавляется в список REDO. В нашем примере мы получим результат: UNDO = {T2, T3, T4}, REDO = {T2, T4}.
3. Когда достигается конец журнала транзакций, оба списка анализируются. При этом из списка UNDO удаляются те транзакции, которые попали в список REDO. В нашем случае получится: UNDO= {T3}, REDO = {T2, T4}.
4. После этого система журнал транзакций просматривает назад, начиная с момента контрольной очки, при этом откатываются все транзакции из списка UNDO. В нашем примере откатятся те операции транзакции T3, которые были выполнены до принятия контрольной точки.
5. Наконец, журнал транзакций просматривает вперед, начиная с момента контрольной точки, при этом повторно выполняются все операции транзакций из списка REDO. В нашем примере, СУБД повторно выполнит все операции транзакции T4 и те операции транзакции T2, которые были выполнены после принятия контрольной точки.

Рассмотренное выше описание методов обеспечения атомарности и долговременности можно считать упрощенным описанием механизмов DB2. К сожалению, ни в литературе, ни в документации Oracle нам не удалось найти исчерпывающего описания механизмов этой СУБД. По имеющимся у нас данным мы можем воссоздать лишь приблизительную картину. Oracle не применяет контрольной точки с принудительным установлением соответствия данных. Перенос данных из оперативной памяти на внешнюю выполняется фоновым процессом СУБД, который выталкивает на внешнюю память те буферы данных, к которым дольше всего не было обращений. Oracle ведет, так называемый, журнал повторений (redo log), в который записывается информация о выполненных транзакцией изменениях. Фоновый процесс обеспечивает достаточно оперативный вывод записей журнала на внешнюю память. (Отметим, что такой подход не гарантирует немедленного вытеснения записей журнала даже при завершении транзакции.) Дополнительная информация, необходимая для восстановления, содержится в управляющих файлах Oracle. По-видимому, в журнал повторений заносятся также записи о переносе данных из оперативной памяти на внешнюю. Как упоминалось выше, Oracle строит для транзакций сегменты отката, содержащие старые версии измененных транзакциями данных. Сегменты отката используются для обеспечения изоляции транзакций, другая их функция - обеспечение отката одиночной транзакции или откатов всех транзакций, прерванных сбоем. Поскольку сегменты отката, как и данные, буферизуются в оперативной памяти, в журнал повторений также заносятся записи, отражающие изменения состояния сегментов отката.

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

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