Что такое транзакция в информатике
Перейти к содержимому

Что такое транзакция в информатике

  • автор:

Транзакция

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

Мы хотим принести в Россию самые передовые облачные технологии и заботимся о каждом пользователе. Политика конфиденциальности Антикоррупционная политика Договор-оферты

Array ( [0] => Array ( [TEXT] => Продукты [LINK] => /arenda-1c/ [SELECTED] => [PERMISSION] => R [ADDITIONAL_LINKS] => Array ( ) [ITEM_TYPE] => D [ITEM_INDEX] => 0 [PARAMS] => Array ( ) [CHAIN] => Array ( [0] => Продукты ) [DEPTH_LEVEL] => 1 [IS_PARENT] => 1 ) [1] => Array ( [TEXT] => Аренда 1С [LINK] => /arenda-1c/ [SELECTED] => [PERMISSION] => R [ADDITIONAL_LINKS] => Array ( ) [ITEM_TYPE] => D [ITEM_INDEX] => 0 [PARAMS] => Array ( ) [CHAIN] => Array ( [0] => Продукты [1] => Аренда 1С ) [DEPTH_LEVEL] => 2 [IS_PARENT] => ) [2] => Array ( [TEXT] => Аренда 1С:Фреш [LINK] => /arenda-1c/1c-fresh/ [SELECTED] => [PERMISSION] => R [ADDITIONAL_LINKS] => Array ( ) [ITEM_TYPE] => D [ITEM_INDEX] => 1 [PARAMS] => Array ( ) [CHAIN] => Array ( [0] => Продукты [1] => Аренда 1С:Фреш ) [DEPTH_LEVEL] => 2 [IS_PARENT] => ) [3] => Array ( [TEXT] => Аренда сервера 1С [LINK] => /arenda-serverov/ [SELECTED] => [PERMISSION] => R [ADDITIONAL_LINKS] => Array ( ) [ITEM_TYPE] => D [ITEM_INDEX] => 2 [PARAMS] => Array ( ) [CHAIN] => Array ( [0] => Продукты [1] => Аренда сервера 1С ) [DEPTH_LEVEL] => 2 [IS_PARENT] => ) [4] => Array ( [TEXT] => Аренда виртуального сервера [LINK] => /arenda-serverov/arenda-virtualnogo-servera/ [SELECTED] => [PERMISSION] => R [ADDITIONAL_LINKS] => Array ( ) [ITEM_TYPE] => D [ITEM_INDEX] => 3 [PARAMS] => Array ( ) [CHAIN] => Array ( [0] => Продукты [1] => Аренда виртуального сервера ) [DEPTH_LEVEL] => 2 [IS_PARENT] => ) [5] => Array ( [TEXT] => Облако 1С [LINK] => /oblako-1c/ [SELECTED] => [PERMISSION] => R [ADDITIONAL_LINKS] => Array ( ) [ITEM_TYPE] => D [ITEM_INDEX] => 4 [PARAMS] => Array ( ) [CHAIN] => Array ( [0] => Продукты [1] => Облако 1С ) [DEPTH_LEVEL] => 2 [IS_PARENT] => ) [6] => Array ( [TEXT] => 1С онлайн [LINK] => /online-1c/ [SELECTED] => [PERMISSION] => R [ADDITIONAL_LINKS] => Array ( ) [ITEM_TYPE] => D [ITEM_INDEX] => 5 [PARAMS] => Array ( ) [CHAIN] => Array ( [0] => Продукты [1] => 1С онлайн ) [DEPTH_LEVEL] => 2 [IS_PARENT] => ) [7] => Array ( [TEXT] => Бухгалтерия Онлайн [LINK] => /buhgalteria-online/ [SELECTED] => [PERMISSION] => R [ADDITIONAL_LINKS] => Array ( ) [ITEM_TYPE] => D [ITEM_INDEX] => 6 [PARAMS] => Array ( ) [CHAIN] => Array ( [0] => Продукты [1] => Бухгалтерия Онлайн ) [DEPTH_LEVEL] => 2 [IS_PARENT] => ) [8] => Array ( [TEXT] => Программы 1С для ИП [LINK] => /programmy-1c-dlya-ip/ [SELECTED] => [PERMISSION] => R [ADDITIONAL_LINKS] => Array ( ) [ITEM_TYPE] => D [ITEM_INDEX] => 7 [PARAMS] => Array ( ) [CHAIN] => Array ( [0] => Продукты [1] => Программы 1С для ИП ) [DEPTH_LEVEL] => 2 [IS_PARENT] => ) [9] => Array ( [TEXT] => Сервисы [LINK] => /1c-contragent/ [SELECTED] => [PERMISSION] => R [ADDITIONAL_LINKS] => Array ( ) [ITEM_TYPE] => D [ITEM_INDEX] => 1 [PARAMS] => Array ( ) [CHAIN] => Array ( [0] => Сервисы ) [DEPTH_LEVEL] => 1 [IS_PARENT] => 1 ) [10] => Array ( [TEXT] => 1С:Контрагент [LINK] => /1c-contragent/ [SELECTED] => [PERMISSION] => R [ADDITIONAL_LINKS] => Array ( ) [ITEM_TYPE] => D [ITEM_INDEX] => 0 [PARAMS] => Array ( ) [CHAIN] => Array ( [0] => Сервисы [1] => 1С:Контрагент ) [DEPTH_LEVEL] => 2 [IS_PARENT] => ) [11] => Array ( [TEXT] => 1С-Отчетность [LINK] => /1c-otchetnost/ [SELECTED] => [PERMISSION] => R [ADDITIONAL_LINKS] => Array ( ) [ITEM_TYPE] => D [ITEM_INDEX] => 1 [PARAMS] => Array ( ) [CHAIN] => Array ( [0] => Сервисы [1] => 1С-Отчетность ) [DEPTH_LEVEL] => 2 [IS_PARENT] => ) [12] => Array ( [TEXT] => 1СПАРК Риски [LINK] => /1c-sparkriski/ [SELECTED] => [PERMISSION] => R [ADDITIONAL_LINKS] => Array ( ) [ITEM_TYPE] => D [ITEM_INDEX] => 2 [PARAMS] => Array ( ) [CHAIN] => Array ( [0] => Сервисы [1] => 1СПАРК Риски ) [DEPTH_LEVEL] => 2 [IS_PARENT] => ) [13] => Array ( [TEXT] => 1С:Распознавание первичных документов [LINK] => /1c-raspoznavanie-pervichnyh-dokumentov/ [SELECTED] => [PERMISSION] => R [ADDITIONAL_LINKS] => Array ( ) [ITEM_TYPE] => D [ITEM_INDEX] => 3 [PARAMS] => Array ( ) [CHAIN] => Array ( [0] => Сервисы [1] => 1С:Распознавание первичных документов ) [DEPTH_LEVEL] => 2 [IS_PARENT] => ) [14] => Array ( [TEXT] => 1С:Кабинет сотрудника [LINK] => https://e-office24.ru/1c-kabinet-sotrudnika/ [SELECTED] => [PERMISSION] => Z [ADDITIONAL_LINKS] => Array ( ) [ITEM_TYPE] => D [ITEM_INDEX] => 4 [PARAMS] => Array ( ) [CHAIN] => Array ( [0] => Сервисы [1] => 1С:Кабинет сотрудника ) [DEPTH_LEVEL] => 2 [IS_PARENT] => ) [15] => Array ( [TEXT] => Поддержка [LINK] => /support/ [SELECTED] => 1 [PERMISSION] => R [ADDITIONAL_LINKS] => Array ( ) [ITEM_TYPE] => D [ITEM_INDEX] => 2 [PARAMS] => Array ( ) [CHAIN] => Array ( [0] => Поддержка ) [DEPTH_LEVEL] => 1 [IS_PARENT] => 1 ) [16] => Array ( [TEXT] => Техническая поддержка [LINK] => /support/ [SELECTED] => 1 [PERMISSION] => R [ADDITIONAL_LINKS] => Array ( ) [ITEM_TYPE] => D [ITEM_INDEX] => 0 [PARAMS] => Array ( ) [CHAIN] => Array ( [0] => Поддержка [1] => Техническая поддержка ) [DEPTH_LEVEL] => 2 [IS_PARENT] => ) [17] => Array ( [TEXT] => Часто задаваемые вопросы [LINK] => /support/faq-voprosy-1c/ [SELECTED] => [PERMISSION] => R [ADDITIONAL_LINKS] => Array ( ) [ITEM_TYPE] => D [ITEM_INDEX] => 1 [PARAMS] => Array ( ) [CHAIN] => Array ( [0] => Поддержка [1] => Часто задаваемые вопросы ) [DEPTH_LEVEL] => 2 [IS_PARENT] => ) [18] => Array ( [TEXT] => Форум 1С [LINK] => /support/forum-1c/ [SELECTED] => [PERMISSION] => R [ADDITIONAL_LINKS] => Array ( ) [ITEM_TYPE] => D [ITEM_INDEX] => 2 [PARAMS] => Array ( ) [CHAIN] => Array ( [0] => Поддержка [1] => Форум 1С ) [DEPTH_LEVEL] => 2 [IS_PARENT] => ) [19] => Array ( [TEXT] => Выбор программы [LINK] => /support/vybor-programmy/ [SELECTED] => [PERMISSION] => R [ADDITIONAL_LINKS] => Array ( ) [ITEM_TYPE] => D [ITEM_INDEX] => 3 [PARAMS] => Array ( ) [CHAIN] => Array ( [0] => Поддержка [1] => Выбор программы ) [DEPTH_LEVEL] => 2 [IS_PARENT] => ) [20] => Array ( [TEXT] => Предоставить доступ [LINK] => /support/connect/ [SELECTED] => [PERMISSION] => R [ADDITIONAL_LINKS] => Array ( [TEST] => Y ) [ITEM_TYPE] => D [ITEM_INDEX] => 4 [PARAMS] => Array ( ) [CHAIN] => Array ( [0] => Поддержка [1] => Предоставить доступ ) [DEPTH_LEVEL] => 2 [IS_PARENT] => ) [21] => Array ( [TEXT] => О нас [LINK] => /company/ [SELECTED] => [PERMISSION] => R [ADDITIONAL_LINKS] => Array ( ) [ITEM_TYPE] => D [ITEM_INDEX] => 3 [PARAMS] => Array ( ) [CHAIN] => Array ( [0] => О нас ) [DEPTH_LEVEL] => 1 [IS_PARENT] => 1 ) [22] => Array ( [TEXT] => О проекте [LINK] => /company/ [SELECTED] => [PERMISSION] => R [ADDITIONAL_LINKS] => Array ( ) [ITEM_TYPE] => D [ITEM_INDEX] => 0 [PARAMS] => Array ( ) [CHAIN] => Array ( [0] => О нас [1] => О проекте ) [DEPTH_LEVEL] => 2 [IS_PARENT] => ) [23] => Array ( [TEXT] => Новостной блог [LINK] => /news/ [SELECTED] => [PERMISSION] => R [ADDITIONAL_LINKS] => Array ( ) [ITEM_TYPE] => D [ITEM_INDEX] => 1 [PARAMS] => Array ( ) [CHAIN] => Array ( [0] => О нас [1] => Новостной блог ) [DEPTH_LEVEL] => 2 [IS_PARENT] => ) [24] => Array ( [TEXT] => Отзывы клиентов [LINK] => /company/otzyvy-klientov/ [SELECTED] => [PERMISSION] => R [ADDITIONAL_LINKS] => Array ( ) [ITEM_TYPE] => D [ITEM_INDEX] => 2 [PARAMS] => Array ( ) [CHAIN] => Array ( [0] => О нас [1] => Отзывы клиентов ) [DEPTH_LEVEL] => 2 [IS_PARENT] => ) [25] => Array ( [TEXT] => Контакты [LINK] => /company/contacts/ [SELECTED] => [PERMISSION] => R [ADDITIONAL_LINKS] => Array ( ) [ITEM_TYPE] => D [ITEM_INDEX] => 3 [PARAMS] => Array ( ) [CHAIN] => Array ( [0] => О нас [1] => Контакты ) [DEPTH_LEVEL] => 2 [IS_PARENT] => ) )
  • Продукты
    • Аренда 1С
    • Аренда 1С:Фреш
    • Аренда сервера 1С
    • Аренда виртуального сервера
    • Облако 1С
    • 1С онлайн
    • Бухгалтерия Онлайн
    • Программы 1С для ИП
    • 1С:Контрагент
    • 1С-Отчетность
    • 1СПАРК Риски
    • 1С:Распознавание первичных документов
    • 1С:Кабинет сотрудника
    • Техническая поддержка
    • Часто задаваемые вопросы
    • Форум 1С
    • Выбор программы
    • Предоставить доступ
    • О проекте
    • Новостной блог
    • Отзывы клиентов
    • Контакты

    vk

    +7 (804) 333-16-02 звонок по России бесплатный Москва: +7 (499) 649-16-02 Санкт-Петербург: +7 (812) 425-17-02 Екатеринбург: +7 (343) 222-16-02 info@e-office24.ru sales@e-office24.ru

    Круглосуточная техническая поддержка пользователей

    Транзакция (информатика)

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

    Различают последовательные (обычные), параллельные и распределённые транзакции. Распределённые транзакции подразумевают использование больше чем одной транзакционной системы и требуют намного более сложной логики (например, two-phase commit — двухфазный протокол фиксации транзакции). Также, в некоторых системах реализованы автономные транзакции, или под-транзакции, которые являются автономной частью родительской транзакции.

    Пример транзакции

    Пример: необходимо перевести с банковского счёта номер 5 на счёт номер 7 сумму в 10 денежных единиц. Этого можно достичь, к примеру, приведённой последовательностью действий:

    • Начать транзакцию
    • Окончить транзакцию

    Эти действия представляют собой логическую единицу работы «перевод суммы между счетами», и таким образом, являются транзакцией. Если прервать данную транзакцию, к примеру, в середине, и не аннулировать все изменения, легко оставить владельца счёта номер 5 без 10 единиц, тогда как владелец счета номер 7 их не получит.

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

    Основная статья: ACID

    Одним из наиболее распространённых наборов требований к транзакциям и транзакционным системам является набор ACID (Atomicity, Consistency, Isolation, Durability). Вместе с тем, существуют специализированные системы с ослабленными транзакционными свойствами [1] .

    Уровни изоляции транзакций

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

    • 0 — Неподтверждённое чтение (Read Uncommitted, Dirty Read, грязное чтение) — чтение незафиксированных изменений своей транзакции и параллельных транзакций, возможны нечистые, неповторяемые чтения и фантомы
    • 1 — Подтверждённое чтение (Read Committed) — чтение всех изменений своей транзакции и зафиксированных изменений параллельных транзакций, нечистые чтения невозможны, возможны неповторяемые чтения и фантомы;
    • 2 — Повторяемое чтение (Repeatable Read, Snapshot) — чтение всех изменений своей транзакции, любые изменения, внесённые параллельными транзакциями после начала своей, недоступны, нечистые и неповторяемые чтения невозможны, возможны фантомы;
    • 3 — Упорядоченный — (Serializable, сериализуемый) — упорядоченные (сериализуемые) транзакции. Идентичен ситуации, при которой транзакции выполняются строго последовательно, одна после другой, то есть результат действия которых не зависит от порядка выполнения шагов транзакции (запрещено чтение всех данных, изменённых с начала транзакции, в том числе и своей транзакцией). Фантомы невозможны.

    Чем выше уровень изоляции, тем больше требуется ресурсов, чтобы их поддерживать.

    В СУБД уровень изоляции транзакций можно выбрать как для всех транзакций сразу, так и для одной конкретной транзакции. По умолчанию в большинстве баз данных используется уровень 1 (Read Committed). Уровень 0 используется в основном для отслеживания изменений длительных транзакций или для чтения редко изменяемых данных. Уровни 2 и 3 используются при повышенных требованиях к изолированности транзакций.

    Реализация

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

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

    • Журнализация изменений (write ahead logging, WAL)
    • механизм теневых страниц (shadow paging) [2] .

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

    При упреждающей журнализации, используемой в Sybase и MS SQL Server до версии 2005, все изменения записываются в журнал, и только после успешного завершения — в базу данных. Это позволяет СУБД вернуться в рабочее состояние после неожиданного падения системы. Теневые страницы содержат копии тех страниц базы данных на начало транзакции, в которых происходят изменения. Эти копии активизируются после успешного завершения. Хотя теневые страницы легче реализуются, упреждающая журнализация более эффективна [3]

    Дальнейшее развитие технологий управления базами данных привело к появлению безблокировочных технологий. Идея контроля за параллельным доступом с помощью временных меток (timestamp-based concurrency control) была развита и привела к появлению многоверсионной архитектуры MVCC. Эти технологии не нуждаются ни в журнализации изменений, ни в теневых страницах. Архитектура, реализованная в Oracle 7.х и выше, записывает старые версии страниц в специальный сегмент отката, но они все ещё доступны для чтения. Если транзакция при чтении попадает на страницу, временная метка которой новее начала чтения, данные берутся из сегмента отката (то есть используется «старая» версия). Для поддержки такой работы ведётся журнал транзакций, но в отличие от «упреждающей журнализации», он не содержит данных. Работа с ним состоит из трёх логических шагов:

    1. Записать намерение произвести некоторые операции
    2. Выполнить задание, копируя оригиналы изменяемых страниц в сегмент отката
    3. Записать, что всё сделано без ошибок

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

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

    Firebird вообще не имеет ни журнала изменений, ни сегмента отката, а реализует MVCC, записывая новые версии строк таблиц прямо в активное пространство данных. Так же поступает MS SQL 2005. Теоретически это даёт максимальную эффективность при параллельной работе с данными, но ценой является необходимость «сборки мусора», то есть удаления старых и уже не нужных версий данных.

    См. также

    В Викисловаре есть статья «транзакция»

    • Транзакционная система
    • ACID
    • Атомарные операции

    Примечания

    1. Advanced Transaction Models and Architectures (англ.)
    2. Семейство алгоритмов ARIES
    3. Gray, J., McJones, P., Blasgen, M., Lindsay, B., Lorie, R., Price, T., Putzolu, F., and Traiger, I. The recovery manager of the System R database manager. ACM Comput. Surv. 13, 2 (June 1981).

    Транзакция информатика У этого термина существуют и другие значения см Транзакция значения Транза кция англ transaction

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

    Различают последовательные (обычные), параллельные и распределённые транзакции. Распределённые транзакции подразумевают использование более чем одной транзакционной системы и требуют намного более сложной логики (например, two-phase commit — двухфазный протокол фиксации транзакции). Также в некоторых системах реализованы автономные транзакции, или подтранзакции, которые являются автономной частью родительской транзакции.

    Пример транзакции Править

    Пример: необходимо перевести с банковского счёта номер 5 на счёт номер 7 сумму в 10 денежных единиц. Этого можно достичь, к примеру, приведённой последовательностью действий:

    1. Прочесть баланс на счету номер 5.
    2. Уменьшить баланс на 10 денежных единиц.
    3. Сохранить новый баланс счёта номер 5.
    4. Прочесть баланс на счету номер 7.
    5. Увеличить баланс на 10 денежных единиц.
    6. Сохранить новый баланс счёта номер 7.

    Эти действия представляют собой логическую единицу работы «перевод суммы между счетами», и таким образом, являются транзакцией. Если прервать данную транзакцию, к примеру, в середине, и не аннулировать все изменения, легко оставить владельца счёта номер 5 без 10 единиц, тогда как владелец счета номер 7 их не получит.

    Свойства транзакций Править

    Основная статья: ACID

    Одним из наиболее распространённых наборов требований к транзакциям и транзакционным системам является набор ACID (Atomicity, Consistency, Isolation, Durability). Требования ACID были в основном сформулированы в конце 1970-х годов Джимом Греем. Вместе с тем существуют специализированные системы с ослабленными транзакционными свойствами.

    Уровни изоляции транзакций Править

    Основная статья: Уровни изолированности транзакций

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

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

    • 0 — Чтение незафиксированных данных (Read Uncommitted) — чтение незафиксированных изменений как своей транзакции, так и параллельных транзакций. Нет гарантии, что данные, изменённые другими транзакциями, не будут в любой момент изменены в результате их отката, поэтому такое чтение является потенциальным источником ошибок. Невозможны потерянные изменения (lost changes), возможны грязное чтение (dirty read), неповторяемое чтение и фантомы.
    • 1 — Чтение зафиксированных данных (Read Committed) — чтение всех изменений своей транзакции и зафиксированных изменений параллельных транзакций. Потерянные изменения и грязное чтение не допускается, возможны неповторяемое чтение и фантомы.
    • 2 — Повторяемое чтение (Repeatable Read, Snapshot) — чтение всех изменений своей транзакции, любые изменения, внесённые параллельными транзакциями после начала своей, недоступны. Потерянные изменения, грязное и неповторяемое чтение невозможны, возможны фантомы.
    • 3 — Сериализуемый (Serializable) — сериализуемые транзакции. Результат параллельного выполнения сериализуемой транзакции с другими транзакциями должен быть логически эквивалентен результату их какого-либо последовательного выполнения. Проблемы синхронизации не возникают.

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

    В СУБД уровень изоляции транзакций можно выбрать как для всех транзакций сразу, так и для одной конкретной транзакции. По умолчанию в большинстве баз данных используется уровень 1 (Read Committed). Уровень 0 используется в основном для отслеживания изменений длительных транзакций или для чтения редко изменяемых данных. Уровни 2 и 3 используются при повышенных требованиях к изолированности транзакций.

    Реализация Править

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

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

    • журнализация изменений (write ahead logging, WAL);
    • механизм теневых страниц (shadow paging).

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

    При упреждающей журнализации, используемой в Sybase и MS SQL Server до версии 2005, все изменения записываются в журнал, и только после успешного завершения — в базу данных. Это позволяет СУБД вернуться в рабочее состояние после неожиданного падения системы. Теневые страницы содержат копии тех страниц базы данных на начало транзакции, в которых происходят изменения. Эти копии активизируются после успешного завершения. Хотя теневые страницы легче реализуются, упреждающая журнализация более эффективна.

    Дальнейшее развитие технологий управления базами данных привело к появлению безблокировочных технологий. Идея контроля над параллельным доступом с помощью временных меток (timestamp-based concurrency control) была развита и привела к появлению многоверсионной архитектуры MVCC. Эти технологии не нуждаются ни в журнализации изменений, ни в теневых страницах. Архитектура, реализованная в Oracle 7.х и выше, записывает старые версии страниц в специальный сегмент отката, но они все ещё доступны для чтения. Если транзакция при чтении попадает на страницу, временная метка которой новее начала чтения, данные берутся из сегмента отката (то есть используется «старая» версия). Для поддержки такой работы ведётся журнал транзакций, но в отличие от «упреждающей журнализации», он не содержит данных. Работа с ним состоит из трёх логических шагов:

    1. Записать намерение произвести некоторые операции
    2. Выполнить задание, копируя оригиналы изменяемых страниц в сегмент отката
    3. Записать, что всё сделано без ошибок

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

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

    Firebird вообще не имеет ни журнала изменений, ни сегмента отката, а реализует MVCC, записывая новые версии строк таблиц прямо в активное пространство данных. Так же поступает MS SQL 2005. Теоретически это даёт максимальную эффективность при параллельной работе с данными, но ценой является необходимость «сборки мусора», то есть удаления старых и уже не нужных версий данных.

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

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

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

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

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

    Транзакции оформлены в строгом хронологическом порядке. Если сделка N+1 намерена коснуться той же части базы данных что и транзакция N, транзакция N+1 не начинается до момента совершения транзакции N. До совершения любых транзакций, все остальные транзакции, затрагивающие ту же часть системы, также должны быть завершены; не может быть никаких «дырок» в последовательности предыдущих транзакций.

    Методология Править

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

    Системы обработки транзакций обеспечивают целостность базы данных при помощи записи промежуточного состояния базы данных перед её изменением, а затем, используя эти записи, восстанавливают базу данных до известного состояния, если транзакция не может быть совершена. Например, копии информации в базе данных до её изменения транзакцией, делаются системой перед транзакцией, которая может сделать любые изменения (иногда это называют before image). Если какая-либо часть транзакции не удается до её совершения, эти копии используются для восстановления базы данных в состояние, в котором она находилась до начала транзакции (Rollback).

    Кроме того, можно вести отдельный журнал всех изменений базы данных (иногда это называется after images); это не требует отката неудачных операций, но это полезно для обновления базы данных в случае отказа базы данных, поэтому некоторые системы обработки транзакций обеспечивают эту функцию. Если база данных отказывает совсем, она должна быть восстановлена из последней резервной. Резервные копии не будут отражать операции, совершенные после её создания. Однако, как только будет восстановлена база данных, журнал after images может быть применен к базе данных (rollforward), чтобы привести её в актуальное состояние. Любые транзакции, которые находятся в процессе на момент сбоя, могут быть свернуты. Результат представляет собой базу данных в известном согласованном состоянии, которое включает результаты всех транзакций, совершенных до момента отказа.

    В некоторых случаях, две транзакции могут в ходе их обработки пытаться получить доступ к одной и той же части базы данных в одно и то же время, таким образом, что это будет препятствовать их совершению. Например, транзакция А может получить доступ к части Х базы данных, и транзакция В может получить доступ к Y части базы данных. Если в этот момент транзакция А пытается получить доступ к части Y базы данных, в то время как транзакция B пытается получить доступ к части X, возникает ситуация взаимоблокировки, и ни одна транзакция не может быть произведена. Системы обработки транзакций предназначены для обнаружения таких ситуаций. Обычно обе транзакции отменяются и производится откат, а затем они автоматически запускаются в другом порядке, так что взаимоблокировка не повторится. Или иногда, только одна из транзакций, попавших в тупик, отменяется, производится откат, и автоматически повторяется после небольшой задержки.

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

    См. также Править

    В Викисловаре есть статья « транзакция »
    • Транзакционная система
    • ACID
    • Атомарные операции
    • Программная транзакционная память
    • MVCC

    Примечания Править

    1. Gray, Jim. The Transaction Concept: Virtues and Limitations. Proceedings of the 7th International Conference on Very Large Databases: pages 144—154, 1981(англ.)
    2. Advanced Transaction Models and Architectures(англ.)
    3. Семейство алгоритмов ARIES20 сентября 2008 года.
    4. Gray, J., McJones, P., Blasgen, M., Lindsay, B., Lorie, R., Price, T., Putzolu, F., and Traiger, I. The recovery manager of the System R database manager. ACM Comput. Surv. 13, 2 (June 1981).
    5. ↑ Ahmed K. Elmagarmid (Editor), Transaction Models for Advanced Database Applications, Morgan-Kaufmann, 1992, ISBN 1-55860-214-3
    6. ↑ Gerhard Weikum, Gottfried Vossen, Transactional information systems: theory, algorithms, and the practice of concurrency control and recovery, Morgan Kaufmann, 2002, ISBN 1-55860-508-8
    7. Philip A. Bernstein, Eric Newcomer, Principles of Transaction Processing, 1997, Morgan Kaufmann, ISBN 1-55860-415-4

    Википедия, чтение, книга, библиотека, поиск, нажмите, истории, книги, статьи, wikipedia, учить, информация, история, скачать, скачать бесплатно, mp3, видео, mp4, 3gp, jpg, jpeg, gif, png, картинка, музыка, песня, фильм, игра, игры

    Дата публикации: Октябрь 22, 2023, 10:25 am
    Самые читаемые

    Тюфяков, Михаил Вячеславович

    Тэдори

    Тяньцзиньский инцидент

    Тянклисъега

    Тыркова-Вильямс, Ариадна Владимировна

    Тырговиште (футбольный клуб)

    Ты побеждаешь или умираешь

    Трыстиково (Бургасская область)

    Трутовский, Владимир Евгениевич

    Труды Линнеевского общества Лондона

    © Copyright 2021, Все права защищены.

    U etogo termina sushestvuyut i drugie znacheniya sm Tranzakciya znacheniya Tranza kciya angl transaction gruppa posledovatelnyh operacij s bazoj dannyh kotoraya predstavlyaet soboj logicheskuyu edinicu raboty s dannymi Tranzakciya mozhet byt vypolnena libo celikom i uspeshno soblyudaya celostnost dannyh i nezavisimo ot parallelno idushih drugih tranzakcij libo ne vypolnena voobshe i togda ona ne dolzhna proizvesti nikakogo effekta Tranzakcii obrabatyvayutsya tranzakcionnymi sistemami v processe raboty kotoryh sozdayotsya istoriya tranzakcij Razlichayut posledovatelnye obychnye parallelnye i raspredelyonnye tranzakcii Raspredelyonnye tranzakcii podrazumevayut ispolzovanie bolee chem odnoj tranzakcionnoj sistemy i trebuyut namnogo bolee slozhnoj logiki naprimer two phase commit dvuhfaznyj protokol fiksacii tranzakcii Takzhe v nekotoryh sistemah realizovany avtonomnye tranzakcii ili podtranzakcii kotorye yavlyayutsya avtonomnoj chastyu roditelskoj tranzakcii Soderzhanie 1 Primer tranzakcii 2 Svojstva tranzakcij 3 Urovni izolyacii tranzakcij 4 Realizaciya 5 Obrabotka tranzakcij 5 1 Metodologiya 6 Sm takzhe 7 PrimechaniyaPrimer tranzakcii PravitPrimer neobhodimo perevesti s bankovskogo schyota nomer 5 na schyot nomer 7 summu v 10 denezhnyh edinic Etogo mozhno dostich k primeru privedyonnoj posledovatelnostyu dejstvij Prochest balans na schetu nomer 5 Umenshit balans na 10 denezhnyh edinic Sohranit novyj balans schyota nomer 5 Prochest balans na schetu nomer 7 Uvelichit balans na 10 denezhnyh edinic Sohranit novyj balans schyota nomer 7 Eti dejstviya predstavlyayut soboj logicheskuyu edinicu raboty perevod summy mezhdu schetami i takim obrazom yavlyayutsya tranzakciej Esli prervat dannuyu tranzakciyu k primeru v seredine i ne annulirovat vse izmeneniya legko ostavit vladelca schyota nomer 5 bez 10 edinic togda kak vladelec scheta nomer 7 ih ne poluchit Svojstva tranzakcij PravitOsnovnaya statya ACID Odnim iz naibolee rasprostranyonnyh naborov trebovanij k tranzakciyam i tranzakcionnym sistemam yavlyaetsya nabor ACID Atomicity Consistency Isolation Durability Trebovaniya ACID byli v osnovnom sformulirovany v konce 1970 h godov Dzhimom Greem 1 Vmeste s tem sushestvuyut specializirovannye sistemy s oslablennymi tranzakcionnymi svojstvami 2 Urovni izolyacii tranzakcij PravitOsnovnaya statya Urovni izolirovannosti tranzakcij V ideale tranzakcii raznyh polzovatelej dolzhny vypolnyatsya tak chtoby sozdavalas illyuziya chto polzovatel tekushej tranzakcii edinstvennyj Odnako v realnosti po soobrazheniyam proizvoditelnosti i dlya vypolneniya nekotoryh specialnyh zadach SUBD predostavlyayut razlichnye urovni izolyacii tranzakcij Urovni opisany v poryadke uvelicheniya izolirovannosti tranzakcij i sootvetstvenno nadyozhnosti raboty s dannymi 0 Chtenie nezafiksirovannyh dannyh Read Uncommitted chtenie nezafiksirovannyh izmenenij kak svoej tranzakcii tak i parallelnyh tranzakcij Net garantii chto dannye izmenyonnye drugimi tranzakciyami ne budut v lyuboj moment izmeneny v rezultate ih otkata poetomu takoe chtenie yavlyaetsya potencialnym istochnikom oshibok Nevozmozhny poteryannye izmeneniya lost changes vozmozhny gryaznoe chtenie dirty read nepovtoryaemoe chtenie i fantomy 1 Chtenie zafiksirovannyh dannyh Read Committed chtenie vseh izmenenij svoej tranzakcii i zafiksirovannyh izmenenij parallelnyh tranzakcij Poteryannye izmeneniya i gryaznoe chtenie ne dopuskaetsya vozmozhny nepovtoryaemoe chtenie i fantomy 2 Povtoryaemoe chtenie Repeatable Read Snapshot chtenie vseh izmenenij svoej tranzakcii lyubye izmeneniya vnesyonnye parallelnymi tranzakciyami posle nachala svoej nedostupny Poteryannye izmeneniya gryaznoe i nepovtoryaemoe chtenie nevozmozhny vozmozhny fantomy 3 Serializuemyj Serializable serializuemye tranzakcii Rezultat parallelnogo vypolneniya serializuemoj tranzakcii s drugimi tranzakciyami dolzhen byt logicheski ekvivalenten rezultatu ih kakogo libo posledovatelnogo vypolneniya Problemy sinhronizacii ne voznikayut Chem vyshe uroven izolyacii tem bolshe trebuetsya resursov chtoby ego obespechit Sootvetstvenno povyshenie izolirovannosti mozhet privodit k snizheniyu skorosti vypolneniya parallelnyh tranzakcij chto yavlyaetsya platoj za povyshenie nadyozhnosti V SUBD uroven izolyacii tranzakcij mozhno vybrat kak dlya vseh tranzakcij srazu tak i dlya odnoj konkretnoj tranzakcii Po umolchaniyu v bolshinstve baz dannyh ispolzuetsya uroven 1 Read Committed Uroven 0 ispolzuetsya v osnovnom dlya otslezhivaniya izmenenij dlitelnyh tranzakcij ili dlya chteniya redko izmenyaemyh dannyh Urovni 2 i 3 ispolzuyutsya pri povyshennyh trebovaniyah k izolirovannosti tranzakcij Realizaciya PravitPolnocennaya realizaciya urovnej izolyacii i svojstv ACID predstavlyaet soboj netrivialnuyu zadachu Obrabotka postupayushih dannyh privodit k bolshomu kolichestvu malenkih izmenenij vklyuchaya obnovlenie kak samih tablic tak i indeksov Eti izmeneniya potencialno mogut poterpet neudachu zakonchilos mesto na diske operaciya zanimaet slishkom mnogo vremeni timeout i t d Sistema dolzhna v sluchae neudachi korrektno vernut bazu dannyh v sostoyanie do tranzakcii Pervye kommercheskie SUBD k primeru IBM DB2 polzovalis isklyuchitelno blokirovkoj dostupa k dannym dlya obespecheniya svojstv ACID No bolshoe kolichestvo blokirovok privodit k sushestvennomu umensheniyu proizvoditelnosti Est dva populyarnyh semejstva reshenij etoj problemy kotorye snizhayut kolichestvo blokirovok zhurnalizaciya izmenenij write ahead logging WAL mehanizm tenevyh stranic shadow paging 3 V oboih sluchayah blokirovki dolzhny byt rasstavleny na vsyu informaciyu kotoraya obnovlyaetsya V zavisimosti ot urovnya izolyacii i implementacii blokirovki zapisi takzhe rasstavlyayutsya na informaciyu kotoraya byla prochitana tranzakciej Pri uprezhdayushej zhurnalizacii ispolzuemoj v Sybase i MS SQL Server do versii 2005 vse izmeneniya zapisyvayutsya v zhurnal i tolko posle uspeshnogo zaversheniya v bazu dannyh Eto pozvolyaet SUBD vernutsya v rabochee sostoyanie posle neozhidannogo padeniya sistemy Tenevye stranicy soderzhat kopii teh stranic bazy dannyh na nachalo tranzakcii v kotoryh proishodyat izmeneniya Eti kopii aktiviziruyutsya posle uspeshnogo zaversheniya Hotya tenevye stranicy legche realizuyutsya uprezhdayushaya zhurnalizaciya bolee effektivna 4 Dalnejshee razvitie tehnologij upravleniya bazami dannyh privelo k poyavleniyu bezblokirovochnyh tehnologij Ideya kontrolya nad parallelnym dostupom s pomoshyu vremennyh metok timestamp based concurrency control byla razvita i privela k poyavleniyu mnogoversionnoj arhitektury MVCC Eti tehnologii ne nuzhdayutsya ni v zhurnalizacii izmenenij ni v tenevyh stranicah Arhitektura realizovannaya v Oracle 7 h i vyshe zapisyvaet starye versii stranic v specialnyj segment otkata no oni vse eshyo dostupny dlya chteniya Esli tranzakciya pri chtenii popadaet na stranicu vremennaya metka kotoroj novee nachala chteniya dannye berutsya iz segmenta otkata to est ispolzuetsya staraya versiya Dlya podderzhki takoj raboty vedyotsya zhurnal tranzakcij no v otlichie ot uprezhdayushej zhurnalizacii on ne soderzhit dannyh Rabota s nim sostoit iz tryoh logicheskih shagov Zapisat namerenie proizvesti nekotorye operacii Vypolnit zadanie kopiruya originaly izmenyaemyh stranic v segment otkata Zapisat chto vsyo sdelano bez oshibokZhurnal tranzakcij v sochetanii s segmentom otkata oblast v kotoroj hranitsya kopiya vseh izmenyaemyh v hode tranzakcii dannyh garantiruet celostnost dannyh V sluchae sboya zapuskaetsya procedura vosstanovleniya kotoraya prosmatrivaet otdelnye ego zapisi sleduyushim obrazom Esli povrezhdena zapis to sboj proizoshyol vo vremya prostavleniya otmetki v zhurnale Znachit nichego vazhnogo ne poteryalos ignoriruem etu oshibku Esli vse zapisi pomecheny kak uspeshno vypolnennye to sboj proizoshyol mezhdu tranzakciyami zdes takzhe net poter Esli v zhurnale est nezavershyonnaya tranzakciya to sboj proizoshyol vo vremya zapisi na disk V etom sluchae my vosstanavlivaem staruyu versiyu dannyh iz segmenta otkata Firebird voobshe ne imeet ni zhurnala izmenenij ni segmenta otkata a realizuet MVCC zapisyvaya novye versii strok tablic pryamo v aktivnoe prostranstvo dannyh Tak zhe postupaet MS SQL 2005 Teoreticheski eto dayot maksimalnuyu effektivnost pri parallelnoj rabote s dannymi no cenoj yavlyaetsya neobhodimost sborki musora to est udaleniya staryh i uzhe ne nuzhnyh versij dannyh Obrabotka tranzakcij PravitObrabotka tranzakcij napravlena na podderzhanie kompyuternoj sistemy kak pravilo bazy dannyh ili kakih libo sovremennyh fajlovyh sistem v izvestnom soglasovannom sostoyanii putyom obespecheniya togo chtoby lyubye operacii osushestvlyayushiesya v sisteme yavlyayutsya vzaimozavisimymi i libo vse uspeshno zaversheny libo polnostyu i uspeshno otmeneny 5 Naprimer rassmotrim tipichnuyu bankovskuyu tranzakciyu kotoraya vklyuchaet v sebya peremeshenie 700 dollarov s sberegatelnogo scheta klienta na raschetnyj schet klienta Eta tranzakciya yavlyaetsya odnoj operaciej dlya banka no ona vklyuchaet v sebya po krajnej mere dve otdelnye operacii v kompyuternyh terminah zachislyayutsya na depozitnyj schet 700 dollarov a takzhe kredituetsya raschetnyj schet na 700 dollarov Esli debetovye operacii proshli uspeshno a kreditnye net ili naoborot v knigah banka ne budet ostatka na konec dnya Poetomu dolzhen byt sposob garantirovat chto obe operacii libo imeli uspeh libo provalilis tak chto nikogda ne byvaet kakih libo nesootvetstvij v baze dannyh banka v celom Obrabotka tranzakcij prednaznachena dlya obespecheniya etogo Obrabotka tranzakcij pozvolyaet neskolkim otdelnym operaciyam avtomaticheski byt svyazannymi drug s drugom kak edinaya nedelimaya tranzakciya Sistemy obrabotki tranzakcij garantiruet chto libo vse operacii v tranzakcii zaversheny bez oshibok libo ni odna iz nih Esli nekotorye iz operacij zaversheny no s oshibkami a drugie bez sistemy obrabotki tranzakcij daet komandu na otkat vseh operacij tranzakcii v tom chisle udachnyh chto oznachaet stiranie vseh sledov operacii i vosstanovlenie sistemy do soglasovannogo izvestnogo sostoyaniya kotoroe bylo do nachala processa tranzakcii Esli vse operacii tranzakcii zaversheny uspeshno to tranzakciya fiksiruetsya v sisteme i vse izmeneniya v baze dannyh stanovyatsya postoyannymi commited tranzakcii ne mogut byt otmeneny esli oni uzhe byli sdelany Obrabotka tranzakcij zashishaet ot apparatnyh i programmnyh oshibok kotorye mogut ostavit tranzakciyu zavershennoj chastichno s sistemoj ostavlennoj v neizvestnom protivorechivom sostoyanii Esli v kompyuternoj sisteme proishodit sboj v seredine tranzakcii obrabotka tranzakcij garantiruet chto vse operacii v lyubyh nezafiksirovannyh to est ne polnostyu obrabotannyh tranzakciyah budut otmeneny Tranzakcii oformleny v strogom hronologicheskom poryadke Esli sdelka N 1 namerena kosnutsya toj zhe chasti bazy dannyh chto i tranzakciya N tranzakciya N 1 ne nachinaetsya do momenta soversheniya tranzakcii N Do soversheniya lyubyh tranzakcij vse ostalnye tranzakcii zatragivayushie tu zhe chast sistemy takzhe dolzhny byt zaversheny ne mozhet byt nikakih dyrok v posledovatelnosti predydushih tranzakcij 6 5 Metodologiya Pravit Osnovnye principy vseh sistem obrabotki tranzakcij odinakovy Odnako terminologiya mozhet varirovatsya ot odnoj sistemy obrabotki tranzakcij do drugoj i terminy ispolzuemye nizhe ne obyazatelno yavlyayutsya universalnymi 7 Otkat angl rollback Sistemy obrabotki tranzakcij obespechivayut celostnost bazy dannyh pri pomoshi zapisi promezhutochnogo sostoyaniya bazy dannyh pered eyo izmeneniem a zatem ispolzuya eti zapisi vosstanavlivayut bazu dannyh do izvestnogo sostoyaniya esli tranzakciya ne mozhet byt sovershena Naprimer kopii informacii v baze dannyh do eyo izmeneniya tranzakciej delayutsya sistemoj pered tranzakciej kotoraya mozhet sdelat lyubye izmeneniya inogda eto nazyvayut before image Esli kakaya libo chast tranzakcii ne udaetsya do eyo soversheniya eti kopii ispolzuyutsya dlya vosstanovleniya bazy dannyh v sostoyanie v kotorom ona nahodilas do nachala tranzakcii Rollback 6 Progon angl rollforward Krome togo mozhno vesti otdelnyj zhurnal vseh izmenenij bazy dannyh inogda eto nazyvaetsya after images eto ne trebuet otkata neudachnyh operacij no eto polezno dlya obnovleniya bazy dannyh v sluchae otkaza bazy dannyh poetomu nekotorye sistemy obrabotki tranzakcij obespechivayut etu funkciyu Esli baza dannyh otkazyvaet sovsem ona dolzhna byt vosstanovlena iz poslednej rezervnoj Rezervnye kopii ne budut otrazhat operacii sovershennye posle eyo sozdaniya Odnako kak tolko budet vosstanovlena baza dannyh zhurnal after images mozhet byt primenen k baze dannyh rollforward chtoby privesti eyo v aktualnoe sostoyanie Lyubye tranzakcii kotorye nahodyatsya v processe na moment sboya mogut byt svernuty Rezultat predstavlyaet soboj bazu dannyh v izvestnom soglasovannom sostoyanii kotoroe vklyuchaet rezultaty vseh tranzakcij sovershennyh do momenta otkaza 6 Vzaimnaya blokirovka angl deadlocks V nekotoryh sluchayah dve tranzakcii mogut v hode ih obrabotki pytatsya poluchit dostup k odnoj i toj zhe chasti bazy dannyh v odno i to zhe vremya takim obrazom chto eto budet prepyatstvovat ih soversheniyu Naprimer tranzakciya A mozhet poluchit dostup k chasti H bazy dannyh i tranzakciya V mozhet poluchit dostup k Y chasti bazy dannyh Esli v etot moment tranzakciya A pytaetsya poluchit dostup k chasti Y bazy dannyh v to vremya kak tranzakciya B pytaetsya poluchit dostup k chasti X voznikaet situaciya vzaimoblokirovki i ni odna tranzakciya ne mozhet byt proizvedena Sistemy obrabotki tranzakcij prednaznacheny dlya obnaruzheniya takih situacij Obychno obe tranzakcii otmenyayutsya i proizvoditsya otkat a zatem oni avtomaticheski zapuskayutsya v drugom poryadke tak chto vzaimoblokirovka ne povtoritsya Ili inogda tolko odna iz tranzakcij popavshih v tupik otmenyaetsya proizvoditsya otkat i avtomaticheski povtoryaetsya posle nebolshoj zaderzhki Vzaimoblokirovki mogut proishodit mezhdu tremya ili bolee tranzakciyami Chem bolshe tranzakcii svyazany tem trudnee ih obnaruzhit Sistemy obrabotki tranzakcij dazhe ustanovili prakticheskoe ogranichenie na tupikovye situacii kotorye oni mogut obnaruzhit Sm takzhe Pravit nbsp V Vikislovare est statya tranzakciya Tranzakcionnaya sistema ACID Atomarnye operacii Programmnaya tranzakcionnaya pamyat MVCCPrimechaniya Pravit Gray Jim The Transaction Concept Virtues and Limitations Proceedings of the 7th International Conference on Very Large Databases pages 144 154 1981 angl Advanced Transaction Models and Architectures angl Semejstvo algoritmov ARIES Arhivirovano 20 sentyabrya 2008 goda Gray J McJones P Blasgen M Lindsay B Lorie R Price T Putzolu F and Traiger I The recovery manager of the System R database manager ACM Comput Surv 13 2 June 1981 1 2 Ahmed K Elmagarmid Editor Transaction Models for Advanced Database Applications Morgan Kaufmann 1992 ISBN 1 55860 214 3 1 2 3 Gerhard Weikum Gottfried Vossen Transactional information systems theory algorithms and the practice of concurrency control and recovery Morgan Kaufmann 2002 ISBN 1 55860 508 8 Philip A Bernstein Eric Newcomer Principles of Transaction Processing 1997 Morgan Kaufmann ISBN 1 55860 415 4 Istochnik https ru wikipedia org w index php title Tranzakciya informatika amp oldid 127772615

    Транзакционность — Основы реляционных баз данных

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

    Запросы внутри транзакции

    Допустим, у нас есть таблица счетов accounts, в которой две записи:

    id user_id amount
    1 10 100
    2 30 100

    Процесс перевода можно представить так:

      Получаем количество денег пользователя:

    SELECT amount FROM accounts WHERE user_id = 10; 
    UPDATE accounts SET amount = amount - 50 WHERE user_id = 10; 
    UPDATE accounts SET amount = amount + 50 WHERE user_id = 30; 

    В результате таблица примет следующий вид:

    id user_id amount
    1 10 50
    2 30 150

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

    id user_id amount
    1 10 50
    2 30 100

    Такое может произойти не только с деньгами, но и в большинстве других ситуаций. Приложения по возможности должны находиться в согласованном состоянии. В распределенных системах это невозможно, добиться этого можно с помощью механизма транзакций. Мы не будем подробно разбирать эту тему, но вы можете узнать о ней больше, изучив CAP-теорему и Eventual Consistency .

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

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

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

    BEGIN; SELECT amount FROM accounts WHERE user_id = 10; UPDATE accounts SET amount = amount - 50 WHERE user_id = 10; UPDATE accounts SET amount = amount + 50 WHERE user_id = 30; COMMIT; 

    Транзакции в PostgreSQL — это блок запросов, который обрамляется запросами:

    • BEGIN — открытие транзакции
    • COMMIT — закрытие транзакции

    Любая ошибка внутри транзакции откатывает все изменения, которые были сделаны после запроса BEGIN :

    Если нужно, транзакцию можно откатить самостоятельно. Для этого необходимо выполнить запрос ROLLBACK до COMMIT . Это нужно, когда выполняются запросы из кода приложения.

    BEGIN; UPDATE accounts SET amount = amount - 50 WHERE user_id = 10; ROLLBACK; 

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

    Требования к транзакционной системе

    В информатике есть набор требований к транзакционной системе, которые гарантируют ее надежность — ACID. К ним относятся:

    • Atomicity (Атомарность)
    • Consistency (Согласованность)
    • Isolation (Изолированность)
    • Durability (Устойчивость)

    Разберем каждое требование подробнее

    Atomicity (Атомарность)

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

    Consistency (Согласованность)

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

    В примере выше снятие денег с одного счета приводит к тому, что данные рассинхронизированы. Но когда транзакция завершается, этого нет.

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

    Isolation (Изолированность)

    Когда транзакция выполняется, параллельные транзакции не должны оказывать влияния на ее результат. Ни одна транзакция не может увидеть изменения, которые сделаны другими незавершенными транзакциями. Изолированность — дорогое требование, поэтому в реальных БД существуют режимы, которые изолируют транзакцию не полностью — уровни изолированности Repeatable Read и ниже.

    Durability (Устойчивость)

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

    Открыть доступ

    Курсы программирования для новичков и опытных разработчиков. Начните обучение бесплатно

    • 130 курсов, 2000+ часов теории
    • 1000 практических заданий в браузере
    • 360 000 студентов

    Наши выпускники работают в компаниях:

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *