Транзакции. Свойства acid транзакций. Управление восстановлением. Алгоритм aries. Двухфазная фиксация.

 

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

 

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

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

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

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

 

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

 

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

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

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

 

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

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

 

Транзакции обладают (или должны обладать) четырьмя важными свойствами (ACID):

- Неразрывность (atomicity). Транзакции неразрывны (выполняются по принципу «все или ничего»).

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

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

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

 

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

Локальное нарушение по определению влияет только на ту транзакцию, в которой оно, собственно говоря, и произошло. Глобальное нарушение воздействует сразу на все транзакции, выполнявшиеся в момент его возникновения.

Такие отказы подразделяются на две основные категории:

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

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

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

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

1. Создаются два списка транзакций: UNDO (Отменить) и REDO (Выполнить повторно).
2. В список UNDO заносятся все транзакции, упомянутые в последней из существующих записей контрольной точки, а список REDO пока остается пустым.
3. В журнале регистрации поиск начинается с записи контрольной точки и происходит в прямом направлении.
4. Если в журнале регистрации обнаружена запись BEGINTRANSACTION с указанием о начале выполнения некоторой транзакции Т, то эта транзакция добавляется в список UNDO.
5. Если в журнале регистрации обнаружена запись COMMIT, свидетельствующая об окончании выполнения некоторой транзакции Т, эта транзакция переносится из списка UNDO в список REDO.
6. По достижении конца файла журнала регистрации списки UNDO и REDO анализируются.

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

 

Алгоритм ARIES

Аббревиатура ARIES расшифровывается как «Algorithms for Recovery and Isolation Exploiting Semantics» (Алгоритмы восстановления и изоляции на основе семантики).

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

Выполнение процедур алгоритма ARIES подразделяется на описанные ниже три основных этапа.

1. Анализ. Формирование списков REDO (накат) и UNDO (откат).
2. Накат. Начиная с позиции журнала, которая определена на этапе анализа, восстановление базы данных до того состояния, в котором она находилась во время аварийного останова.
3. Откат. Отмена результатов внесения изменений теми транзакциями, фиксация которых не была выполнена.

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

 

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

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

Процедура восстановления носителей подразумевает наличие в системе утилиты копирования/восстановления (или выгрузки/загрузки). Функция копирования этой утилиты используется для создания резервной копии в установленные моменты. [До сюда]

 

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

Описание последовательности работы координатора:

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

Если принудительная выгрузка прошла успешно, диспетчер ресурсов отвечает координатору, что «подготовка завершилась успешно». В противном случае он посылает противоположное по смыслу сообщение — «подготовка окончилась неудачей».

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

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

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

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