33. Транзакции. Связь с ограничениями целостности.
34. Модель транзакций ansi/iso. (включен в ответ к 33)
Понятие транзакции
Поддержание механизма транзакций - показатель развитости СУБД. Корректное поддержание транзакций одновременно является основой обеспечения целостности базы данных, а также составляет базис изолированности пользователей в многопользовательских СУБД.
Транзакция представляет собой последовательность операторов языка SQL, которая рассматривается как некоторое неделимое действие над базой данных, осмысленное с точки зрения пользователя. Транзакция - это логическая единица работы, выполняемая базой данных. Она может быть представлена отдельной программой, являться частью алгоритма программы или даже отдельной командой (например, командой insert) и включать произвольное количество операций, выполняемых в базе данных.
Например, если имеется структура данных следующего вида: «Персонал (номер, фамилия, адрес, телефон, должность, зарплата)», то простейшей транзакцией может быть модификация зарплаты определенного работника.
Традиционное понимание транзакции может быть охарактеризовано четырьмя классическими свойствами: атомарности (atomicity), согласованности (consistency), изолированности (isolation) и долговечности (прочности) (durability)- ACID. Эти свойства означают следующее:
свойство атомарности выражается в том, что транзакция должна быть выполнена в целом или не выполнена вообще;
свойство согласованности гарантирует, что по мере выполнения транзакций данные переходят из одного согласованного состояния в другое - не нарушается взаимная согласованность данных;
свойство изолированности означает, что конкурирующие за доступ к базе данных транзакции физически обрабатываются последовательно, изолированно друг от друга, но для пользователей это выглядит так, как будто они выполняются параллельно; промежуточные результаты незавершенной транзакции не должны быть доступны другим транзакциям;
свойство долговечности трактуется следующим образом: если транзакция завершена успешно, то те изменения, которые были произведены в данных, не могут быть потеряны ни при каких обстоятельствах.
Транзакции и целостность баз данных.
Возможны два варианта завершения работы транзакции. Если все операторы выполнены успешно и в процессе выполнения транзакции не произошло никаких сбоев программного или аппаратного обеспечения, транзакция фиксируется. Фиксация транзакции (commit)- это действие, обеспечивающее запись на диск изменений в базе данных, которые были сделаны в ходе выполнения транзакции. До тех пор, пока транзакция не зафиксирована, возможно произвести отмену всех изменений и восстановить базу данных в исходное, на момент начала транзакции, состояние. Фиксация означает, что все результаты выполнения транзакции становятся постоянными и доступными другим пользователям системы. Надо отметить, что до момента фиксации транзакции пользователи имеют дело с данными, в том виде, в котором они находились на момент начала выполнения текущей транзакции.
Если же в процессе работы случилось нечто, что делает выполнение транзакции невозможным, база данных возвращается в исходное состояние. Откат транзакции (roll back)- это действие, обеспечивающее аннулирование всех изменений данных, которые были сделаны операторами SQL в теле текущей незавершенной транзакции.
Если оказывается, что зафиксированная транзакция является ошибочной, то требуется выполнить другую транзакцию, отменяющую действия, выполненные первой транзакцией. Такая транзакция называется компенсирующей.
В стандарте ANSI/ISO SQL определены модель транзакций и функции операторов COMMIT и ROLLBACK. Стандарт определяет, что транзакция начинается с первого SQL-оператора, инициируемого пользователем или содержащемся в программе. Все последующие операторы составляют тело транзакции. Транзакция завершается одним из четырех возможных вариантов (рис.1):
оператор COMMIT означает успешное завершение транзакции; его использование делает постоянными изменения, внесенные в базу данных в рамках текущей транзакции;
оператор ROLLBACK прерывает транзакцию, отменяя все изменения, сделанные в рамках текущей транзакции; новая транзакция начинается непосредственно после оператора ROLLBACK;
успешное завершение программы, в которой была инициирована текущая транзакция, означает успешное завершение транзакции (аналогично работе оператора COMMIT);
ошибочное завершение программы прерывает выполнение транзакции (аналогично работе оператора ROLLBACK).
Рис 1
Различаются два вида ограничений целостности: немедленно проверяемые и откладываемые. К немедленно проверяемым относятся ограничения целостности, проверку которых бессмысленно или невозможно откладывать (например, ограничение на возрастные рамки - более 150 лет). Эти ограничения целостности соответствуют уровню отдельных операторов языка СУБД и при их нарушении производится не откат транзакции, а лишь отвергается определенный оператор. Откладываемые ограничения - это ограничения на базу данных, а не на какие-либо отдельные операции. По умолчанию такие ограничения проверяются в конце транзакции, и их нарушение вызывает автоматическую замену оператора COMMIT на оператор ROLLBACK. Однако в некоторых системах поддерживается специальный оператор насильственной поддержки ограничений целостности внутри транзакций.
Возможности отката и фиксации транзакция обеспечивается благодаря наличию в СУБД функции ведения журнала транзакций.
Параллельное выполнение транзакций.
В том случае, если с базой данных одновременно работают несколько пользователей, СУБД должна не только корректно выполнить индивидуальные транзакции и восстанавливать согласованное состояние базы данных, но и обеспечить корректную параллельную работу всех пользователей над одними и теми же данными.
Рассмотрим фрагмент полной схемы построения СУБД, включающих четыре высокоуровневых модуля, отвечающих за выполнение и обработку транзакций, управление параллельностью и выполнение восстановления системы (рис.2).
Рис.2 Подсистема обработка транзакций типичной СУБД.
Менеджер транзакций осуществляет координацию работы транзакций, выполняемых прикладными программами. Он взаимодействует с планировщиком (менеджер блокировок), отвечающим за реализацию выбранной стратегии управления параллельностью; второе название применимо в том случае, если выбран протокол управления на основе системы блокировок. Цель работы планировщика – достижение максимально возможного уровня параллельности, при условии исключения влияния параллельно выполняющихся транзакций друг на друга, поскольку это может послужить источником нарушения согласованности базы данных. Если в процессе выполнения транзакции происходит откат, то база данных может находиться в несогласованном состоянии. Задачей менеджера восстановления является предоставление гарантий того, что в подобном случае база данных будет автоматически восстановлена в то состояние, в котором она находилась на момент начала выполнения транзакции. Менеджер буферов отвечает за передачу данных основной памяти компьютера и вторичной дисковой памяти.
Исходя из теории, что каждый пользователь и каждая транзакция должны обладать свойством изолированности, они должны выполняться так, как если бы только один пользователь работал с базой данных. Средства СУБД позволяют изолировать пользователей друг от друга, однако в этом случае возникают проблемы с замедлением работы. Рассмотрим проблемы, возникающие при параллельной обработке транзакций; их принято подразделять на 4 класса:
Пропавшие (незафиксированные) изменения. Эта ситуация может возникнуть, возникнуть в том случае, когда две транзакции одновременно выполняют изменения в одной и той же записи. Например, два оператора работают на приеме заказов. Первый оператор принял заказ на 30 мониторов, в то время как на складе хранилось 40 мониторов. Получив подтверждение на заказ от покупателя, оператором был выставлен счет на это количество товара и оформлена покупка (обновление записи о количестве товара на складе – 10). В это же время второй оператор принимает заказ на 20 мониторов, принимая во внимание начальное их количество на складе – 40 штук, и также оформляет покупку (также выполняет команду обновить для количества товара на складе- 10). Таким образом, было продано 50 мониторов, в то время как фактически их количество – 40, и на складе существует положительный остаток в 10 ед. База данных находится в несогласованном состоянии, по той причине, что изменения, сделанные операторами были проигнорированы.
Проблемы промежуточных данных. Рассмотрим эту же ситуацию. Первый оператор ведет переговоры с заказчиком и указывает в заказе 30 мониторов, однако перед окончательным выставлением счета он намеревается уточнить некоторые характеристики товара. На диске уже зафиксированы изменения в остатках товара на складе, произведенные первым оператором (остаток – 10 ед. товара). В это время второй оператор работает над формированием собственного заказа на 20 ед. товара, и последние данные по остаткам товара не позволяют ему этот заказ сформировать; приложение второго оператора оканчивает работу. После уточнения характеристик покупаемого товара, первый заказчик отказывается от покупки 30 мониторов, и приложение первого оператора выполняет откат транзакции, возвращая нас к исходному значению товара на складе в 40 ед. Такая ситуация сложилась по той причине, что в процессе выполнения второй транзакции был открыт доступ к данным, которые сформировала первая транзакция.
Проблема несогласованных данных. Представим себе, что, начиная работать почти одновременно, оба оператора получают информацию о наличие на складе 40 ед. товара. Первый оператор завершает переговоры со своим клиентом и продает ему 30 ед. товара; транзакция завершается оператором COMMIT. Состояние базы данных расценивается как непротиворечивое. Пока второй оператор согласовывал условия заказа, он получает новое состояние склада, которое уже успело измениться. База данных находится в непротиворечивом состоянии, однако второй оператор считает, что нарушена целостность выполнения его транзакции. Это состояние возникло по той причине, что транзакция первого оператора смогла изменить кортеж с данными, который уже был прочитан второй транзакцией.
Проблемы строк - признаков. Предположим, что необходимо подготовить два отчета за анализируемый период: стандартный и расширенный. В то время когда приложение печати начинает формировать первый отчет, оператор принимает еще один заказ, укладывающийся в указанный период. Это приводит к тому, что к моменту формирования расширенного отчета в базе данных появились новые данные. Полученные отчеты в рамках одной транзакции содержат противоречивые данные. Это вызвано тем, что, хотя базы данных находилась в согласованном состоянии, приложения печати работали некорректно.