Обработка транзакций

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

Традиционные транзакции характеризуются четырьмя свой­ствами: атомарности, согласованности, изолиро­ванности, долговечности (прочности) — ACID (Atomicity, Consistency, Isolation, Durability). Иногда традицион­ные транзакции называют ACID-транзакциями. Упомянутые выше свойства означают следующее:

• атомарность — операции транзакции образуют нераздели­мый, атомарный блок с определенным началом и концом. Этот блок либо выполняется от начала до конца, либо не выполняется вообще. Если в процессе выполнения тран­закции произошел сбой, происходит откат (backup, воз­врат) к исходному состоянию;

• согласованность гарантирует, что по мере выполнения транзакций данные переходят из одного согласованного состояния в другое — транзакция не разрушает взаимной согласованности данных;

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

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

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

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

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

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

Каждый оператор в транзакции выполняет свою часть рабо­ты, но для успешного завершения всей работы в целом требуется безусловное завершение их всех. Группирование операторов в транзакции сообщает СУБД, что вся эта группа должна быть вы­полнена как единое целое, причем такое выполнение должно поддерживаться автоматически.

В стандарте ANSI/ISO SQL определены модель транзакций и функции операторов commit и rollback. Стандарт определяет, что транзакция начинается с первого SQL-оператора, инииии руемого пользователем или содержащегося в программе. Все по следующие SQL-операторы составляют тело транзакции. Транзакция завершается одним из четырех возможных способов

(рис 5.П):

• оператор commit означает успешное завершение транзак­ции; его использование делает постоянными изменения, внесенные в базу данных в рамках текущей транзакции;

• оператор rollback прерывает транзакцию, отменяя изме­нения, сделанные в базе данных в рамках этой транзакции; новая транзакция начинается непосредственно после использования rollback;

• успешное завершение программы, в которой была иниции­рована текущая транзакция, означает успешное завершение транзакции (как будто был использован оператор commit);

• ошибочное завершение программы прерывает транзакцию (как будто был использован оператор rollback).

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

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

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

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

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

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

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

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

• если две транзакции, А и В, выполняются параллельно, то СУБД полагает, что результат будет такой же, как если бы:

– транзакция А выполнялась первой, а за ней была выпол­нена транзакция В;

– транзакция В выполнялась первой, а за ней была выпол­нена транзакция А.

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

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

На практике могут происходить взаимоблокировки несколь­ких транзакций. Для их предотвращения СУБД периодически проверяет блокировки, установленные активными транзакция­ми. Если СУБД обнаруживает взаимоблокировки, она выбира­ет одну из транзакций, вызвавшую ситуацию взаимоблокиров­ки, и прерывает ее. Это освобождает данные для внесения изменений конкурирующей транзакцией, разрешая тупиковую ситуацию.

В современной литературе часто встречается термин OLTP (Оn - Line Transaction Processing), который обычно переводят как «оперативная обработка транзакций», т. е. выполнение транзакции в режиме реального времени. Система OLTP обязана учитывать жесткие временные требования, следующие из специфики прикладной области. Например, процедура покупки и оформления авиабилета должна происходить быстро и не задерживать очередь. Система, регистрирующая продажи билетов должна обрабатывать одновременно несколько сотен запросов (транзакций), поступающих от множества продавцов авиабилетов. Требования по скорости обработки запроса могут бьггк очень жесткими, однако вызваны они требованиями реальной жизни. Если говорить о прикладных областях OLTP, то это прежде всего, центры кредитных карточек, системы резервиро­вания авиабилетов и мест в отелях, телекоммуникационные системы и т. д.