Построение базы данных

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

1.                 Первая фаза начинается с выдачи координатором всем менеджерам ресурсов указания подготовиться к завершению транзакции "тем или иным способом". На практике это означает, что каждый участник процесса, т.е. каждый менеджер ресурсов, должен принудительно выгрузить все записи журнала регистрации для используемых транзакцией локальных ресурсов в собственный физический жур­нал регистрации (т.е. из первичной во вторичную энергонезависимую память).  Теперь, что бы ни случилось, менеджер ресурсов будет иметь постоянную запись о работе, выполненной им в процессе обработки данной транзакции, а значит, в случае необходимости сможет зафиксировать выполненные обновления или от­менить их. Если принудительная разгрузка прошла успешно, менеджер ресурсов отвечает координатору, что все "ОК". В противном случае он посылает противо­положное сообщение — "Not OK".

2.                 Вторая фаза наступает после того, как координатор получит соответствующие ответы от всех участников. Сначала он принудительно выгружает записи о за­вершаемой транзакции в собственный физический журнал регистрации, фикси­руя свое решение относительно этой транзакции. Если все поступившие ответы были "ОК", то координатор принимает решение глобально зафиксировать дан­ную транзакцию. Если же поступил хотя бы один ответ "Not ОК", то для тран­закции будет выполнен глобальный откат. Затем координатор каким-либо спосо­бом информирует каждого из участников транзакции о своем решении и каждый участник согласно поступившей инструкции должен или локально зафиксиро­вать транзакцию, или выполнить ее откат. Обратите внимание, что каждый участник должен делать то, что ему велел координатор в ходе выполнения вто­рой фазы; в этом и состоит суть данного протокола. Обратите также внимание, что именно появление записи этого решения в физическом журнале регистрации координатора и отмечает переход от фазы 1 к фазе 2.

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

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

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

Глава 2.  Проблемы параллельности и их  решение

2.1.         Проблемы параллельности

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

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

Работа транзакций в смеси. Транзакция рассматривается как последовательность элементарных атомарных операций. Атомарность отдельной элементарной операции состоит в том, что СУБД гарантирует, что, с точки зрения пользователя, будут выполнены два условия:

      Эта операция будет выполнена целиком или не выполнена вовсе (атомарность - все или ничего).

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

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

,

,

то реальная последовательность, в которой СУБД выполняет эти транзакции может быть, например, такой:

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

Каким образом транзакции различных пользователей могут мешать друг другу?

Различают три основные проблемы параллелизма:

      Проблема потери результатов обновления.

      Проблема незафиксированной зависимости (чтение "грязных" данных, неаккуратное считывание).

      Проблема несовместимого анализа.

Рассмотрим подробно эти проблемы.

Рассмотрим две транзакции, A и B, запускающиеся в соответствии с некоторыми графиками. Пусть транзакции работают с некоторыми объектами базы данных, например со строками таблицы. Операцию чтение строки будем обозначать , где - прочитанное значение. Операцию записи значения в строку будем обозначать .

Проблема потери результатов обновления.

Две транзакции по очереди записывают некоторые данные в одну и ту же строку и фиксируют изменения.

Таблица 1.  Пример потери результатов обновления.

Результат. После окончания обеих транзакций, строка содержит значение , занесенное более поздней транзакцией B. Транзакция A ничего не знает о существовании транзакции B, и естественно ожидает, что в строке содержится значение . Таким образом, транзакция A потеряла результаты своей работы. Транзакция A дважды выполняет выборку строк с одним и тем же условием. Между выборками вклинивается транзакция B, которая добавляет новую строку, удовлетворяющую условию отбора.

Таблица 2. Пример проблемы незафиксированной зависимости.

Транзакция A ничего не знает о существовании транзакции B, и, т.к. сама она не меняет ничего в базе данных, то ожидает, что после повторного отбора будут отобраны те же самые строки.

Результат. Транзакция A в двух одинаковых выборках строк получила разные результаты.

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

Пусть на всех счетах находятся одинаковые суммы, например, по 100 условных единиц. Короткая транзакция в этот момент выполняет перевод 50 у.е. с одного счета на другой так, что общая сумма по всем счетам не меняется.

Таблица 3. Пример ошибки собственно-несовместимый анализа.