5. Распределенная транзакция в рбд кис

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

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

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

Большинство выполняемых действий над данными производится в теле транзакций. По умолчанию каждая SQL-команда выполняется как самостоятельная транзакция.

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

В режиме автоматически фиксируемых транзакций неявная транзакция стартует автоматически (SQL-операторы, которые являются началом новой транзакции в неявном режиме: ALTER TABLE, CREATE, DELETE, DROP, FETCH, GRANT, INSERT, OPEN, REVOKE, SELECT, TRUNCATE TABLE, UPDATE), а по завершении также автоматически подтверждается или отменяется. Если выполнение SQL-оператора заканчивается успешно, произведенные им изменения будут зафиксированы. Если же при выполнении оператора произошла ошибка, то для всех произведенных им изменений будет инициирован откат. По умолчанию SQL Server работает в режиме автоматически фиксируемых транзакций. В дальнейшем пользователь может установить на уровне сеанса режим явных транзакций.

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

Не каждая SQL-операция может быть выполнена в рамках транзакции. Не выполняются те операции, для которых невозможно выполнить откат:

CREATE DATABASE, ALTER DATABASE, DROP DATABASE, BACKUP (резервное копирование), RESTORE (восстановление), RECONFIGURE (изменение параметров настройки сервера), UPDATE STATISICS (обновление статистики).

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

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

Характеристики транзакций описываются в терминах ACID.

Atomicity, Consistency, Isolation, Durability – неделимость(атомарность), согласованность(целостность), изолированность, устойчивость(живучесть).

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

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

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

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

Указанные выше правила выполняет СУБД-сервер.

СБОИ ТРАНЗАКЦИЙ

Изолированность между транзакциями может быть далеко несовершенной, и это может проявляться, как:

• грязное чтение;

• неповторяющееся чтение;

• фантомные строки.

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

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

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

когда подтвержденные изменения транзакции1 видны в транзакции2, этот эффект называют неповторяющимся чтением

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

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

УРОВНИ ТРАНЗАКЦИИ

СУБД справляется со всеми тремя видами ошибок транзакций, изолируя транзакции друг от друга. Уровни изоляции можно сравнить с высотой ограды между транзакциями – они позволяют устанавливать критерии допустимости ошибок. В спецификации ANSI-SQL определены четыре уровня изоляции:

Уровень изоляции	Грязное чтение	Неповторяющееся чтение	Фантомные строки	Блокировка записи
	возможность видеть неподтвержденные изменения другой транзакции	возможность видеть подтвержденные изменения другой транзакции	отбор предложением Select дополнительных строк, внесенных другой транзакцией	первая операция записи блокируется второй
Read Uncommited наименее жесткий	допустимо	допустимо	допустимо	нет
Read Сommited принят по умолчанию	запрещено	допустимо	допустимо	нет
Repeatable Read	запрещено	запрещено	допустимо	нет
Serializable наиболее жесткий	запрещено	запрещено	запрещено	нет
Snapshot	запрещено	запрещено	допустимо	да

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

Уровень 1. Read Uncommited - наименее строгий уровень изоляции не предотвращает никаких ошибок транзакций. Он подобен отсутствию забора, так как на самом деле не изолирует транзакции. Установка этого уровня транзакции является аналогом указанию SQL серверу не выполнять блокировки. Этот режим лучше всего подходит для отчетов и приложений чтения данных.

Уровень 2. Read Сommited - позволяет избежать самой опасной ошибки транзакций, но не нагружает систему излишними блокировками.

Уровень 3. Repeatable Read - предотвращая грязное чтение и неповторяющееся чтение, этот уровень обеспечивает повышенную изоляцию транзакций без чрезмерных блокировок, характерных для уровня изоляции 4.

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

Выйдя за пределы стандарта ANSI, разработчики SQL Server добавили еще один уровень изоляции – Snapshot, который создает еще одну копию данных в своем собственном физическом пространстве. Эта копия абсолютно изолирована от других транзакций. Уровень изоляции Snapshot реализует блокировку на уровне базы данных. Как правило, конфликт конкуренции происходит между процессами чтения и записи. В случае Snapshot изоляции создается мгновенный снимок данных для обновления, во время обновления операции чтения продолжают работать с исходными данными. Как только обновление будет подтверждено, будет записана измененная копия данных. Но если второй процесс записи попытается обновить ресурс, который в данный момент уже обновляется, то первый процесс будет заблокирован. Уровень изоляции Snapshot использует версионность строк, записывая их копии во временную базу.

ТРАНЗАКЦИИ в РБД

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

Для реализации распределенной транзакции предусмотрен протокол двухфазной фиксации (two-phase commit). Для описания протокола используется следующая модель.

Имеется ряд независимых транзакций-участников распределенной транзакции, выполняющихся под управлением транзакции-координатора. Решение об окончании распределенной транзакции принимается координатором – менеджером транзакций TM. После этого выполняется первая фаза завершения транзакции, когда координатор передает каждому из участников сообщение "подготовиться к завершению". Получив такое сообщение, каждый участник переходит в состояние готовности, как к немедленному завершению транзакции, так и к ее откату. В терминах СУБД это означает, что буфер журнала с записями об изменениях базы данных участника выталкивается во внешнюю память, но синхронизационные захваты не снимаются. После этого каждый участник, успешно выполнивший подготовительные действия, посылает координатору сообщение "готов к завершению". Если координатор получает такие сообщения ото всех участников, то он начинает вторую фазу завершения, рассылая всем участникам сообщение "завершить транзакцию", и это считается завершением распределенной транзакции. Если не все участники успешно выполнили первую фазу, то координатор рассылает всем участникам сообщение "откатить транзакцию", и тогда эффект воздействия распределенной транзакции на состояние баз данных отсутствует.

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

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

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

Согласованность состояния баз данных при параллельном выполнении нескольких транзакций обеспечивается механизмами блокировок и временных отметок:

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

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

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

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

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