2. Изолированность пользователей

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

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

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

1. Первый уровень - отсутствие потерянных изменений. Рассмотрим следующий сценарий совместного выполнения двух транзакций. Транзакция 1 изменяет объект базы данных А. До завершения транзакции 1 транзакция 2 также изменяет объект А. Транзакция 2 завершается оператором ROLLBACK (например, по причине нарушения ограничений целостности). Тогда при повторном чтении объекта А транзакция 1 не видит изменений этого объекта, произведен­ных ранее. Такая ситуация называется ситуацией потерянных изменений. Естественно, она про­тиворечит требованию изолированности пользователей. Чтобы избежать такой ситуации в транзакции 1 требуется, чтобы до завершения транзакции 1 никакая другая транзакция не могла изменять объект А. Отсутствие потерянных изменений является минимальным требованием к СУБД по части синхронизации параллельно выполняемых транзакций.

2. Второй уровень - отсутствие чтения "грязных данных". Рассмотрим следующий сцена­рий совместного выполнения транзакций 1 и 2. Транзакция 1 изменяет объект базы данных А. Параллельно с этим транзакция 2 читает объект А. Поскольку операция изменения еще не за­вершена, транзакция 2 видит несогласованные "грязные" данные (в частности, операция тран­закции 1 может быть отвернута при проверке немедленно проверяемого ограничения целостно­сти). Это тоже не соответствует требованию изолированности пользователей (каждый пользо­ватель начинает свою транзакцию при согласованном состоянии базы данных и в праве ожи­дать видеть согласованные данные). Чтобы избежать ситуации чтения "грязных" данных, до за­вершения транзакции 1, изменившей объект А, никакая другая транзакция не должна читать объект А (минимальным требованием является блокировка чтения объекта А до завершения операции его изменения в транзакции 1).

3. Третий уровень - отсутствие неповторяющихся чтений. Рассмотрим следующий сцена­рий. Транзакция 1 читает объект базы данных А. До завершения транзакции 1 транзакция 2 из­меняет объект А и успешно завершается оператором COMMIT. Транзакция 1 повторно читает объект А и видит его измененное состояние. Чтобы избежать неповторяющихся чтений, до за­вершения транзакции 1 никакая другая транзакция не должна изменять объект А. В большинст­ве систем это является максимальным требованием к синхронизации транзакций, хотя, как мы увидим немного позже, отсутствие неповторяющихся чтений еще не гарантирует реальной изо­лированности пользователей.

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

К более тонким проблемам изолированности транзакций относится так называемая пробле­ма кортежей-"фантомов", вызывающая ситуации, которые также противоречат изолированно­сти пользователей. Рассмотрим следующий сценарий. Транзакция 1 выполняет оператор А вы­борки кортежей отношения R с условием выборки S (т.е. выбирается часть кортежей отношения R, удовлетворяющих условию S). До завершения транзакции 1 транзакция 2 вставляет в отно­шение R новый кортеж г, удовлетворяющий условию S, и успешно завершается. Транзакция 1 повторно выполняет оператор А, и в результате появляется кортеж, который отсутствовал при первом выполнении оператора. Конечно, такая ситуация противоречит идее изолированности транзакций и может возникнуть даже на третьем уровне изолированности транзакций. Чтобы избежать появления кортежей-фантомов, требуется более высокий "логический" уровень син­хронизации транзакций. Идеи такой синхронизации (предикатные синхронизационные захваты) известны давно, но в большинстве систем не реализованы.

Сериализация транзакций

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

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

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

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

Между транзакциями могут существовать следующие виды конфликтов:

W-W - транзакция 2 пытается изменять объект, измененный не закончившейся транзакцией 1;

R-W - транзакция 2 пытается изменять объект, прочитанный не закончившейся транзакцией;

W-R - транзакция 2 пытается читать объект, измененный не закончившейся транзакцией 1.

Практические методы сериализации транзакций основывается на учете этих конфликтов.

Методы сериализации транзакций

Существуют два базовых подхода к сериализации транзакций:

• основанный на синхронизационных захватах объектов базы данных

• основанный на использовании временных меток.

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