DBMS-транзакции

Всем бобра! Мы активно расширяем наш, так сказать, ассортимент курсов, и вот рады представить новый: «Реляционные СУБД» ^[1]. Курс создан одним из ведущих преподавателей курса «Администратор Linux» ^[2] — Алексеем Цыкуновым ^[3]. В остальном всё будет как обычно: полезности и открытые уроки ^[4], на которых Алексей будет делиться разными вещами, что не входят в сам курс.

Поехали!

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

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

Аккаунт А

Open_Account(A)
Old_Balance = A.balance
New_Balance = Old_Balance - 500
A.balance = New_Balance
Close_Account(A)

Аккаунт Б

Open_Account(B)
Old_Balance = B.balance
New_Balance = Old_Balance + 500
B.balance = New_Balance
Close_Account(B)

Свойства ACID

Транзакция в системе базы данных должна сохранять Атомарность (Atomicity), Согласованность (Consistency), Изолированность (Isolation) и Устойчивость (Durability) — сокращенно ACID — для обеспечения точности, полноты и целостности данных:

• Атомарность — это свойство показывает, что транзакция должна рассматриваться как атомная единица, то есть выполняются либо все ее операции, либо ни одной. В базе данных не должно быть состояний, в которых транзакция завершена частично. Состояния должны быть заданы либо перед началом выполнения транзакции, либо после выполнения/прерывания/неудачного завершения транзакции.
• Согласованность — это свойство показывает, что база данных должна оставаться в согласованном состоянии после любой транзакции. Никакая транзакция не должна оказывать негативного эффекта на данные, находящиеся в базе. Если база данных была в согласованном состоянии до выполнения транзакции, то должна оказаться в нем и после ее выполнения.
• Изолированность — в системе базы данных, где несколько транзакций совершаются одновременно и параллельно, свойство изолированности показывает, что каждая транзакция будут проведена и выполнена, как если бы она была единственной транзакцией в системе. Никакая транзакция не должна влиять на существование других транзакций.
• Устойчивость — это свойство показывает, что база данных должна быть достаточно устойчива для хранения всех последних обновлений, даже если система совершает ошибку или перезагружается. Если проведение транзакции приводит к обновлению фрагмента данных в базе, то эти изменения должны продолжить храниться в базе. Если транзакция производится, но система крашится перед тем, как записать данные на диск, данные должны обновиться сразу после перезапуска системы.

Сериализация

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

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

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

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

Эквивалентные расписания

Эквивалентные расписания могут быть следующих типов:

Эквивалентность результата

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

Эквивалентность представления

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

К примеру:

• Если T читает изначальные данные в S1, то он также читает изначальные данные в S2.
• Если T читает значение написанное J в S1, то он также читает значение написанное J в S2.
• Если T выполняет финальную запись значений в S1, то он также выполняет финальную запись значений в S2.

Эквивалентность конфликта

Два расписания будут конфликтовать, если они обладают следующими свойствами:

• Они принадлежат разным транзакциям.
• Они обращаются к одним и тем же данным.
• Как минимум одно из них — операция “записи”.

Два расписания с несколькими транзакциями с конфликтующими операциями считаются эквивалентными конфликтом только в том случае, если:

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

Примечание — расписания эквивалентные по представлению являются сериализуемыми по представлению, а конфликт-эквивалентные — конфликт-сериализуемыми. Все конфликт-сериализуемые расписания являются сериализуемыми по представлению.

Состояния Транзакций

Транзакция в базе данных может находиться в следующих состояниях:

• Активная (Active) — в этом состоянии транзакция начинает исполняться. Это изначальное состояние любой транзакции.
• Частично Совершенная (Partially Committed) — когда транзакция совершает свою финальную операцию, считается, что она находится в частично совершенном состоянии.
• Неудавшаяся — транзакция считается неудавшейся, если одна из проверок, совершенных системой восстановления базы данных, завершилась неудачно. Такая транзакция не сможет продолжиться.
• Прерванная — если какая-то проверка закончилась неудачно и транзакция перешла в неудавшееся состояние, менеджер восстановления откатит все операции записи в базе данных, чтобы вернуть ее в оригинальное состояние до начала выполнения транзакции.
  Транзакции в таком состоянии считаются прерванными. Модуль восстановления базы данных может выбрать одну из двух операций после прерывания транзакции:
  • Перезапустить транзакцию;
  • Отменить транзакцию.
• Совершённая — если транзакция успешно выполнила все операции, ее считаюсь совершенной. Все ее эффекты на постоянной основе зафиксированы в системе базы данных.

THE END

Как всегда ждём комментарии, вопрос, которые можно задать как тут, так и на открытом уроке ^[4] у Алексея ^[3].

Автор: MaxRokatansky

Источник ^[5]