14. Организация многопользовательского доступа

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

Возможными путями устранения противоречий являются:

1. Организация параллельного доступа.

2. Разделение прав доступа. Разные пользователю обладают различными правами (только чтение, чтение/запись, возможность доступа к разным уровням данным…).

Ниже будет рассмотрена возможность организация параллельного доступа к БД.

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

1) потерянное обновление — при одновременном изменении одного блока данных разными транзакциями, одно из изменений теряется;

Т1	Т2	Состояние
ЧтА		А0
	ЧтА	А0
ИзмА		А1
	ИзмА	А2
	[откат]	[А0]
ЧтА		А2 [А0]

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

Решение – запрет изменения данных, измененных другой транзакцией, до завершения этой транзакции.

2) «грязное чтение» — чтение данных, добавленных или изменённых транзакцией, которая впоследствии не подтвердится (откатится). Либо – чтение второй транзакцией данных, которые могут быть лишь промежуточными (неокончательными).

Пример: обрабатываются A и B – связанные данные (они могут быть получены в результате некоторого вычислительного алгоритма)

Т1	Т2	Состояние
ЧтА		А0 B0
ЧтВ		B0 A0
ИзмА		А1 B0 – грязные данные
	ЧтА	A1 B0
	ЧтВ	A1 B0
ИзмВ		A1 B1

В результате вторая транзакция прочитала неверные (несвязанные) данные.

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

Решение – запрет чтения данных, изменяемых другой транзакцией, до завершения последней.

3) неповторяющееся чтение — ситуация, когда при повторном чтении в рамках одной транзакции, ранее прочитанные данные оказываются изменёнными

Т1	Т2	Состояние
ЧтА		A0
	ЧтА	A0
	ИзмА	A1
ЧтА		A1

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

В результате имеем нарушение изолированности.

Решение – запрет изменения данных, читаемых другой транзакцией, до завершения транзакции:

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

Исходные данные – набор данных {A}

Т1	Т2
Чт {А}
	Доб. в {A}
Чт {А}

Решение: запрещать добавление записей до завершения другой транзакции.

Управление транзакциями. Основные стратегии.

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

Стандарт SQL-92 определяет следующие четыре уровня изоляции, установка которых предотвращает определенные конфликтные ситуации («+» – предотвращает, «–» – не предотвращает):

Уровень	Запрет читать измененные данные	Запрет изменять прочитанные данные	Запрет добавления	Примечание
read uncommitted (чтение незафиксированных данных)	–	–	–	Низший уровень изоляции. Гарантирует только отсутствие потерянных обновлений.
read committed (чтение фиксированных данных)	+	–	–	Принятый по умолчанию уровень для Microsoft SQL Server. Отсутствует черновое, «грязное» чтение. Тем не менее в процессе работы одной транзакции другая может быть успешно завершена и сделанные ею изменения зафиксированы (не решена проблема неповторяемого чтения)
repeatable read (повторяемость чтения)	+	+	–	Уровень, при котором чтение одной и той же строки или строк в транзакции дает одинаковый результат
Serializable (упорядочиваемость)	+	+	+	Самый высокий уровень изолированности; транзакции полностью изолируются друг от друга

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

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

Существует несколько базовых алгоритмов сериализации транзакций.

1) Последовательное исполнение: выполняется только одна транзакция, остальные ждут ее завершения. Приводит к большим задержкам времени ожидания. Для ускорения следует разрешить любую работу с различными данными и одновременное чтение одних и тех же данных;

2) Использование синхронизационных блокировок: транзакция при обращении к данным накладывает блокировку (захват). Обычно используется два типа блокировок: на чтение и на запись. Если транзакции требуются данные и они свободны, то выполняется работа с данными; если они заблокированы, проверяется возможность совместимости: при совместимости работаем с данными, при несовместимости – ожидаем их освобождения. Блокировки снимаются при завершении транзакции. Для поддержки захватов используется двухфазный протокол синхронизации (двухфазное блокирование).

- 1 фаза – транзакция захватывает данные по мере обращения к ним:

- 2 фаза – одновременное освобождение всех данных по завершению транзакции.

Основной недостаток: возможность взаимоблокировок (тупиков):

При наличии тупика (deadlock) ожидание будет бесконечным, поэтому необходимо нестандартное разрешение. Конфликты блокировок решаются следующими методами:

• полуавтоматический вариант: при обнаружении конфликта посылается запрос пользователю. Пользователь принимает решение – продолжить ожидание или произвести откат транзакции;

• автоматический вариант: при обнаружении конфликта после заданного времени ожидания выполняется автооткат транзакции, первой обнаружившей тупик;

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

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

• вершины типа T, соответствующие транзакциям или выполняющимся потокам. Они образуют первую долю графа;

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

Дуги графа ожидания также имеют двоякий смысл:

• дуги (T, R), идущие из вершины-транзакции T в вершину-ресурс R, обозначают, что данный ресурс уже захвачен транзакцией

• дуги (R, T), идущие из вершины-ресурса R в вершину-транзакцию T обозначают, что транзакция T ожидает, пока ресурс R будет освобождён.

Простейшие свойства:

1. Ресурс, не имеющий ни одной входящей дуги, является свободным.

2. Если вершина-транзакция имеет некоторое ненулевое количество входящих дуг, то соответствующая транзакция находится в состоянии ожидания.

3. Если между двумя транзакциями T₁  T₂ существует путь, то транзакция T₁ должна быть выполнена (завершена) раньше, чем начнётся выполнение T₂, поскольку последняя требует освобождения некоторых ресурсов, захваченных транзакцией T₁.

Из последнего свойства очевидным образом следует, что ситуации взаимной блокировки соответствует цикл на графе ожидания.

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

• удаление дуг от неожидающих транзакций;

• удаление дуг от свободных данных к транзакциям.

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

3) Временные метки – транзакция при инициализации получает метку – это время начала. При обращении к данным, транзакция помечает его своей меткой. При обнаружении конфликта, метки сравниваются. Более молодая транзакция откатывается

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

• многоуровневое блокирование: для записи, ячейки, массива записей, или всей таблицы (обычно при мелкой блокировке – много меток, при высокой – сразу блокируется большой кусок);

• многоверсионная организация. Применена в InterBase.. Сущность её состоит в том, что все изменения, проводимые над конкретными записями, производятся не над самой записью, а над ее версией. Версия записи - это копия записи, которая создается при попытке ее изменить. Если какой-то транзакции нужно работать с какой-либо записью, транзакция обращается к последней зафиксированной версии записи;

• использование оптимистического буферирования. При этом данные храниться в буфере до тех пор, пока принудительно не выполняется запись в базу. Различают пессимистическое (запись в БД при записи в буфер) и оптимистическое буферирование (запись выполняется после завершения транзакции, но потом проверяется - были ли изменения в данных. Если изменения были, то пользователь получает сообщение об этом.