Проблемы параллелизма транзакций

Проблемы параллелизма транзакций

План лекции

1.  Понятие и проблемы параллелизма транзакций

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

3.  Проблема незафиксированной зависимости

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

Рекомендуемая литература:

Т. Конноли. Базы данных. Проектирование, реализация и сопровождение. Теория и практика.: Пер. с англ. – М.: Изд. дом «Вильямс», 2006. – 1440 с.

1 Понятие и проблемы параллелизма транзакций

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

·  потери результатов обновления (пропавшие изменения);

·  незафиксированной зависимости (чтение "грязных данных");

·  несовместимого анализа.

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

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

Например, работают два оператора на приеме заказов, первый оператор принял заказ на 30 мониторов. Когда он запрашивал склад, то там числилось 40 мониторов, и он, получив подтверждение от клиента, выставил счет и оформил продажу 30 мониторов из 40. Заканчивая работу с данным заказом, он выполняет команду Обновить (UPDATE), которая заносит 10 как остаток мониторов на складе. Параллельно с ним работает второй оператор, который принимает заказ на 20 таких же мониторов и, в свою очередь, запросив состояние склада и получив исходно ту же цифру 40, он успешно оформляет заказ для своего клиента. Заканчивая работу с данным заказом, он выполняет команду Обновить (UPDATE), которая заносит 20 как остаток мониторов на складе. Каждый из менеджеров доволен своей работой, но мы-то знаем, что произошло. Прежде всего, они продали 50 мониторов из наличествующих 40 штук, и далее на складе еще числится 20 подобных мониторов. БД теперь находится в несогласованном состоянии, а у фирмы возникли серьезные проблемы. Изменения, сделанные первым оператором, были проигнорированы программой выполнения заказа, с которой работал второй оператор.

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

Транзакция 1	Время	Транзакция 2
SELECT f2 (f2=40) FROM tbl1 WHERE f1=1;	t1
	t2	SELECT f2 (f2=40) FROM tbl1 WHERE f1=1;
UPDATE tbl1 SET f2=F2-30 (f2=10) WHERE f1=1;	t3
	t4	UPDATE tbl1 SET f2= F2-20 (f2=10) WHERE f1=1
COMMIT	t5	–
–	t6	COMMIT

Проблема пропавших обновлений

3 Проблема незафиксированной зависимости

Незафиксированная зависимость (чтение "грязных данных") возникает в ситуации, если одна транзакция выполняет чтение некоторой строки таблицы БД, которая в данный момент обновляется другой транзакцией, но это обновление еще не зафиксировано. Первая транзакция выполнила чтение «грязных» данных, которых нет и не было в базе данных в результате аннулирования изменения более поздним откатом транзакции второй транзакции.

Рассмотрим проблему одновременной работы двух операторов. Допустим, первый оператор, ведя переговоры со своим заказчиком, ввел заказанные 30 мониторов Приложение, с которым работает первый оператор, изменило остаток мониторов на складе, и там сейчас находится информация о 10 оставшихся мониторах, но перед окончательным оформлением заказа клиент захотел выяснить еще некоторые характеристики товара. В это время второй оператор пытается принять заказ от своего клиента на 20 мониторов, но его приложение показывает, что на складе осталось всего 10 мониторов, и оператор вынужден отказать выгодному клиенту, который идет в другую фирму, весьма неудовлетворенный работой компании. А в этот момент клиент оператора 1 заканчивает обсуждение дополнительных характеристик наших мониторов и принимает весьма невыгодное решение не покупать мониторы, и приложение оператора 1 выполняет откат транзакции, и на складе снова оказывается 40 мониторов. Фирма потеряла выгодного заказчика, но еще хуже было бы, если бы клиент второго оператора согласился на 10 оставшихся мониторов, и приложение, с которым работает оператор два, отработав свой алгоритм, занесло 0 (ноль) оставшихся мониторов на складе, а после этого приложение оператора один снова бы записало исходные 40 мониторов на складе, хотя 10 их них уже проданы. Такая ситуация оказалась возможной потому, что приложение второго оператора имело доступ к промежуточным данным, которые сформировало первое приложение.

Зависимость транзакции 1 от изменений транзакций 2

Транзакция 1	Время	Транзакция 2
SELECT f2 (f2=40) FROM tbl1 WHERE f1=1;	t1
UPDATE tbl1 SET f2=f2-30 (f2=10) WHERE f1=1;	t2
	t3	SELECT f2 (f2=10 FROM tbl1 WHERE f1=1;
	t4	COMMIT
ROLLBACK WORK;	t5

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

Проблема несовместимого анализа имеет три разновидности:

·  неповторяемое чтение;

·  проблема строк-призраков (фантомы);

·  собственно несовместимый анализ.

Неповторяемое чтение возникает тогда, когда между двумя, подряд идущими, операциями чтения транзакции 1 вклинивается транзакция 2, изменяющее считываемое значение в строке таблицы.

Рассмотрим ситуацию с заказом мониторов. Предположим, что ситуация несколько изменилась. И оба оператора начинают работать практически одновременно. Они оба получают начальное состояние склада 40 мониторов, а далее первый оператор успешно завершает переговоры со своим клиентом и продает ему 30 мониторов. Он завершает работу своего приложения, и оно выполняет команду фиксации транзакции COMMIT. Состояние базы данных непротиворечивое. В этот момент, выяснив все тонкости и характеристики мониторов, клиент второго оператора также решает сделать заказ, и второй оператор, повторно получая состояние склада, видит, что оно изменилось. База данных находится в непротиворечивом состоянии, но второй оператор считает, что нарушена целостность его транзакции, в течение выполнения одной работы он получил два различных состояния склада. Эта ситуация возникла потому, что приложение первого оператора смогло изменить кортеж с данными, который уже прочитало приложение второго оператора.

Неповторяемое чтение

Транзакция 1	Время	Транзакция 2
SELECT f2 (f2=40) FROM tbl1 WHERE f1=1;	t1
	t2	SELECT f2 (f2=40) FROM tbl1 WHERE f1=1;
UPDATE tbl1 SET f2=F2-30 (f2=10) WHERE f1=1;	t3
COMMIT	t4
	t5	SELECT f2 (f2=10) FROM tbl1 WHERE f1=1;
	t6	COMMIT

Фантомы появляются в результате вставки новой строки (строк) транзакцией 1 по условию U1 между двумя, подряд идущими, выборками, удовлетворяющими условию U1 и выполняемыми транзакцией 2.

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

Появление строки-призрака в момент времени

Транзакция A	Время	Транзакция B
	t1	SELECT SUM(f2) FROM tbl1 Where f1=10.01.09;
INSERT INTO tbl1 (f1,f2) VALUES (10.01.09,20);	t2
COMMIT	t3
	t4	SELECT f2 FROM tbl1 Where f1=10.01.09;
	t5	COMMIT

В транзакции 2 выполняется SQL-оператор, использующий все значения поля f2. Затем в транзакции 1 выполняется вставка новой строки, приводящая к тому, что повторное выполнение SQL-оператора в транзакции 2 выдаст другой результат. Такая ситуация называется фантомной вставкой и является частным случаем неповторяющегося чтения. При этом, если выполняемый SQL-оператор выбирает не все значения поля f2, а только значение одной строки таблицы (используется предикат WHERE), то выполнение оператора INSERT не приведет к ситуации фантомной вставки.

Рассмотрим проблему собственно несовместимого анализа на примере ситуации, представленной в табл.

Пусть имеется таблица СЧЕТ, содержащая строку {40, 50, 30}, значения которой соответствуют столбцам СЧЕТ1, СЧЕТ2, СЧЕТ3. Транзакция A суммирует баланс счетов, транзакция B переводит сумму 10 со счета 3 на счет 1. Полученный, в результате выполнения транзакции А, результат 110 неверен, так как баланс счетов равен 120. Если этот результат будет зафиксирован в БД, то в ней возникнет проблема несовместимости. Говорят, что транзакция А встретилась с несовместимым состоянием и на его основе выполнен несовместимый анализ. Причем, в отличие от проблемы фантомов, здесь транзакции А и В независимы, так как транзакция В выполнила все обновления до того, как транзакция А извлекла СЧЕТ3.

Несовместимый анализ в транзакции А

Транзакция A	Время	Транзакция B
SELECT Сч1 (Сч1=40) FROM tbl1 WHERE f1=1;	t1	–
SUM=SUM+ Сч1 (SUM=40)	t2
SELECT Сч2 (Сч1=50) FROM tbl1 WHERE f1=1;	t3
SUM=SUM+ Сч2 (SUM=90)	t4
	t5	SELECT Сч3 (Сч3=30) FROM tbl1 WHERE f1=1;
	t6	UPDATE tbl1 SET Сч3= Сч3-10 (Сч3=20);
	t7	SELECT Сч1 (Сч1=40) FROM tbl1 WHERE f1=1;
	t8	UPDATE tbl1 SET Сч1= Сч1+10 (Сч1=50);
	t9	COMMIT
SELECT Сч3 (Сч3=20) FROM tbl1 WHERE f1=1;	t10
SUM=SUM+ Сч3 (SUM=110)	t11
COMMI