9.3.3. Коллизия “Несогласованные данные” - unrepeatable read, inconsistent analysis

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

1 транзакция	2 транзакция	Пояснение
	10	Видимый остаток
10		Видимый остаток
-6		Изменяет кортеж, уже прочитанный вторым оператором
COMMIT
4	4	Видимый остаток вторая Т видит теперь 4, а не 10, хотя только что было 10. Коллизия т. к. 1 Т изменила запись, уже прочитанную 2 Т.

9.3.4. Коллизия “фантом” - phantom

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

Вообще говоря, желательно, чтобы:

1. в ходе транзакции пользователь видел только согласованные данные, а не промежуточные.

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

Для обозначения совокупности этих условий применяется термин сериализация транзакций.

9.4. Уровни изолированности

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

Уровень изолированности	Описание
0	Нет коллизии lost update problem (одни данные может изменять только одна транзакция, другая должна ждать)
1	Нет коллизии dirty read (при изменении данных они должны блокироваться чтобы никто не мог их прочитать, читающие транзакции должны ждать)
2	Нет коллизии unrepeatable read (при чтении данных никто не может их изменить, если они изменяются то никто не должен их читать)
3	Нет коллизии phantom (при выборке по условию никто не должен изменять или вставлять данные по этому условию)

Уровни изолированности транзакций (согласно SQL-92) определяются оператором:

SET TRANSACTION ISOLATION LEVEL <n> [{READ WRITE | READ ONLY}]

<n>	Уровень изолированности
READ UNCOMMITTED	0
READ COMMITTED (по умолчанию в MS SQL Server)	1
REPEATABLE READ (по умолчанию в Interbase Server)	2
SERIALIZABLE	3

Пример.

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

Пусть таблица SUPPLIES имеет следующие данные по бананам соответсвующих поставщиков и дат:

PRICE

30

31

29

28

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

(1) SELECT MAX(PRICE) FROM SUPPLIES WHERE CODEG=<код бананов>

(2) SELECT MIN(PRICE) FROM SUPPLIES WHERE CODEG=<код бананов>

В это время другая программа устраняет ошибочно введенные данные о поставках бананов и вводит правильные:

(1’) DELETE FROM SUPPLIES WHERE CODEG=<код бананов>

(2’) INSERT INTO SUPPLIES (CODEG, CODEC, DAT, WEIGHT, PRICE) VALUES (<код бананов>, <код поставщика>, <дата>, <вес>, 27)

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

Предположим, что вторая программа всегда выполняется на уровне изолированности SERIALIZABLE.

Если первая программа выполняется на уровне изолированности READ UNCOMMITED, то она может вообще не получить никаких данных. Это случится, если ее транзакция начнется и закончиться после окончания (1’), до начала (2’): (1’) (1) (2) (2’). Результат при этом будет: (MIN=NULL, MAX=NULL).

Если первая программа выполняется с уровнем изолированности транзакции READ COMMITED, то она может увидеть только подтвержденные данные, но не обязательно одни и теже. Так, при последовательности (1) (1’) (2’) (2) результат окажется следующим: (MIN=28, MAX=27)!

Если первая программа выполняется с уровнем изолированности транзакции REPEATABLE READ, то для нее ситуация похожа на предыдущий случай, но в дополнение к нему, все, что было прочитано операцией (1), будет видно и в ходе выполнения операции (2). (Даже если к этому времени зафиксирована транзакция, убравшая все записи из базы данных.) Однако могут появиться дополнительные записи. При последовательности (1) (1’) (2’) (2) ответ окажется таким (MIN=28, MAX=30). Это происходит потому, что операция (2), кроме новой записи, вставленной операцией (2’) увидит и все те записи, которые были до выполнения операции (1’).

Если первая программа выполняется с уровнем изолированности SERIALIZABLE, то результат будет основан на данных либо до (1’)(2’) либо после этой транзакции. Но данные в ходе выполнения этой последовательности (второй программы) никак не повлияют на результат. Итак, ответ буде либо (MIN=25, MAX=30) либо (MIN=27, MAX=27)

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

Методы устранения коллизий совместного доступа (иначе говоря, методы изоляции транзакций):

1. Строго последовательное выполнение. Этот метод является самым простым, но крайне неэффективным по времени выполнения совокупности транзакций.

2. Блокировка (синхронизационный захват объекта). Наиболее применим в современных коммерческих СУБД. Однако в рамках этого метода возможны различные стратегии, менее или более сложные. Так, исключительная блокировка таблицы, вовлеченной в транзакцию на все время выполнения транзакции, часто приводит к тому же эффекту, что и первый метод. Поэтому применяются блокировки не таблицы целиком, а только тех страниц (диковых блоков), в которых располагаются записи таблицы, вовлеченные в транзакцию. Некоторые СУБД допускают блокировку отдельных записей, что является еще более мягким условием. Кроме того, применяются и разные типы блокировок. Совместные, разделяемые (shared) блокировки – объекты, заблокированные таким образом допускают чтение разными транзакциями. Монопольные (exclusive) блокировки – объекты, заблокированные таким образом, не доступны до момента окончания транзакции, повлекшей блокировку и применяются при необходимости изменить, вставить или удалить данные.

3. Поддержка множественных версий записей.

Автоматическая транзакция, явная транзакция, вложенные транзакции, распределенные транзакции (двухфазный COMMIT).!!!!!!!!!!!!!!!!!!!!!!

Грануляция блокирования

RID – строка таблицы

Key – диапазон индекса (для решения проблемы фантомов) – на условие WHERE

Page – страница (4K)

Extent – экстент – 8 страниц

Table –таблица и её индексы

DB – база данных

Блокировка на уровне команды (SELECT, UPDATE, INSERT, DELETE):

SELECT NAME FROM DIAG WITH (<n>) WHERE PARENT=5

<n> := [ROWLOCK, PAGLOCK, TABLOCK, TABLOCKX, HOLDLOCK (до конца транзакции а не на операцию),

UPDLOCK (блокировка изменений но не чтения),

NOLOCK, READUNCOMMITED (0 Level, только SELECT),

REPEATABLEREAD. SERIALIZABLE, READPAST (чтение с пропуском строк, блокированных другими транзакциями)]