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

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

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

Чтение фантомов. Допустим, что транзакция Т1 считывает множество всех строк, удовлетворяющих некоторому заданному условию (например, строки всех поставщиков из Парижа). Допустим также, что транзакция Т2 вставляет в таблицу новую строку, которая удовлетворяет этому же условию. Если транзакция Tl вновь повторит ту же операцию выборки, что и раньше, то ею будет обнаружена ранее отсутствовавшая строка - фантом (phantom).

Различные уровни изоляции определяются в терминах приведенных выше случаев нарушения упорядоченности. Соответствующие определения схематически представлены на рис. 15.13.

Puc. 15.13. Уровни изоляции языка SQL

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

В заключение следует повторить, что определения уровня изоляции REPEATABLE READ в стандарте языка SQL и в СУБД DB2 являются совершенно разными. На самом деле уровню REPEATABLE READ в СУБД DB2 соответствует уровень SERIALIZABLE в стандарте языка SQL.

15.10. Резюме

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

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

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

В общем случае нельзя гарантировать безопасность выполнения набора транзакций, если используемый график не полностью упорядочен. Однако в некоторых системах для повышения их производительности и пропускной способности предусмотрена возможность чередующегося выполнения нескольких транзакций с некоторым установленным уровнем изоляции, что на самом деле является не совсем безопасным решением. В этой главе был описан один такой небезопасный уровень , т.е. уровень стабильности курсора (с точки зрения терминологии, принятой в СУБД DB2, хотя в стандарте языка SQL аналогичный уровень называется READ COMMITTED),

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

намерения для родительского объекта этого элемента (в случае кортежа - для переменной-отношения, в которой кортеж содержится). На практике блокировки намерения обычно устанавливаются так же, как S- и Х-блокировки кортежей, т.е. неявным образом. Однако рекомендуется предусмотреть оператор типа LOCK для явной установки (в случае необходимости) блокировок более сильных, чем те, которые устанавливаются системой неявно.

Наконец, в этой главе были кратко описаны средства управления параллельностью, предусмотренные в языке SQL. В стандарте языка SQL средства явной установки блокировки не предусмотрены вовсе, однако в нем поддерживаются различные уровни изоляции (SERIALIZABLE, REPEATABLE READ, READ COMMITTED, READ UNCOMMITTED), которые в СУБД обычно реализуются средствами неявного автоматического блокирования.

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

Упражнения

15.1. Дайте определение поштш упорядочиваемости.

15.2. Дайте подробное описание:

а) протокола двухфазной блокировки;

б) теоремы двухфазной блокировки.

15.3. Пусть даны транзакции Т1, Т2 и ТЗ, которые выполняют следующие операции:

Т1: добавить 1 к А; Т2: удвоить значение А;

ТЗ: вывести значение А на экран, а затем поместить в А значение 1 (здесь А - некоторый объект базы данных).

а) Допустим, что транзакции Т1, Т2 и ТЗ выполняются параллельно. Перечислите все возможные результаты их выполнения, если начальное значение А равно нулю.

б) Допустим, что транзакции Т1, Т2 и ТЗ имеют показанную ниже внутреннюю структуру.