Возникает очевидный вопрос: Как в процессе перезагрузки система узнает, какую транзакцию следует отменить, а какую выполнить повторно? . Ответ заключается в том, что система автоматически создает контрольные точки с некоторым наперед заданным интервалом (обычно, когда в журнале накапливается определенное число записей). Создание контрольной точки означает: а) физическую перезапись ( принудительная разгрузка ) содержимого рабочих буферов базы данных непосредственно в базу данных и б) физическое помещение в файл журнала специальной записи контрольной точки. На рис. 14.3 представлен пример выполнения транзакций до аварийного сбоя системы (время возрастает слева направо).

Время

ТЗ Т4 Т5

Контрольная точка ( время tc)

Отказ системы ( время tf)

Рис. 14.3. Пять воз.можных вариантов выполнения транзакций К этому можно добавить следующие комментарии. Н Отказ системы произощел в момент tf.

Н Ближайщая к моменту tf контрольная точка была создана в момент tc. Н Транзакция Т1 успешно завершена до момента tc.

Транзакция Т2 начата до момента tc и успешно завершена после момента tc, но до момента tf.

Н Транзакция ТЗ также начата до момента tc, но не завершена к моменту tf. Н Транзакция Т4 начата после момента tc и успешно завершена до момента tf. Н Транзакция Т5 также начата после момента tc, но не завершена к моменту tf.

Очевидно, что при перезагрузке системы транзакции типа ТЗ и Т5 должны быть отменены, а транзакции типа Т2 и Т4 - выполнены повторно. Заметьте, что транзакции типа Tl вообще не участвуют в процессе перезагрузки, так как выполненные ими обновления были принудительно занесены в физическую базу данных в момент tc как часть процедуры создании этой контрольной точки. Обратите внимание также на то, что транзакции, завершившиеся неудачно (т.е. для них был выполнен откат) до момента tf, также не будут принимать участия в процессе перезагрузки (подумайте, почему).

Следовательно, во время перезагрузки система прежде всего идентифицирует все транзакции типа Т2-Т5. При этом осуществляются следующие действия.

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

2. В журнале регистрации поиск организуется с записи последней контрольной точки.

3. Если в журнале регистрации обнаружена запись BEGIN TRANSACTION с указанием о начале выполнения некоторой транзакции Т, то эта транзакция добавляется в список UNDO.

4. Если в журнале регистрации обнаружена запись COMMIT, свидетельствующая об окончании выполнения некоторой транзакции Т, эта транзакция добавляется в список REDO.

5. По достижении конца файла журнала регистрации списки UNDO и REDO анализируются для выявления транзакций типа Т2 и Т4, помещенных в список REDO, и транзакций типа ТЗ и Т5, оставшихся в списке UNDO.

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

Замечание. Восстановление согласованного состояния базы данных посредством отмены выполненных операций иногда называется обратным восстановлением. Аналогично восстановление согласованного состояния базы данных за счет повторного выполнения уже выполненных действий называется прямым восстановлением.

И наконец, когда такая восстановительная работа будет завершена, тогда (и только тогда) система будет готова к дальнейшей работе.

14.5. Восстановление носителей

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

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

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

Следует иметь в виду, что описываемая здесь процедура восстановления системы очень упрощена. В частности, здесь показано, что сначала выполняются операции отмены, а затем - операции повторного выполнения Первые системы действительно так работали, но современные системы по соображениям производительности обычно работают несколько иначе (см. [4.17], [4.19]).

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

14.6. Двухфазная фиксация

в этом разделе кратко рассматривается очень важное усовершенствование основной концепции фиксации/отката транзакций, а именно - протокол двухфазной фиксации. Использование этого протокола оказывается важным всякий раз, когда определенная транзакция может взаимодействовать с несколькими независимыми менеджерами ресурсов, каждый из которых распоряжается собственным набором восстанавливаемых ресурсов и поддерживает собственный журнал регистрации. Например, пусть транзакция, выполняемая на мэйнфрейме IBM, модифицирует как базу данных СУБД IMS, так и базу данных СУБД DB2 (между прочим, подобная транзакция вполне допустима). Если транзакция завершается успешно, то все выполненные ею обновления, как в базе данных СУБД IMS, так и в базе данных СУБД DB2, должны быть зафиксированы. В противном случае для всех внесенных обновлений должен быть выполнен откат. Иначе говоря, недопустима ситуация, когда обновления информации в базе данных СУБД IMS зафиксированы, а для обновлений информации в базе данных СУБД DB2 выполнен откат, или наоборот. Суть в том, что в подобном случае транзакция перестанет быть атомарной.

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

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

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

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