Глава 14 Параллелизм

14.1. Введение

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

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

Замечание. Блокировка не является единственным возможным подходом в реше­нии проблемы управления параллелизмом, но она, несомненно, чаще других встреча­ется на практике. Некоторые другие подходы описаны в комментариях, приведенных в списке литературы.

Далее описывается, как можно использовать блокировку для решения про­блем, о которых идет речь в начале главы. Однако с внедрением метода блоки­ровки возникают другие проблемы; среди них наиболее известна проблема тупи­ковых ситуаций, которая и описывается ниже в этой главе. Затем описывается концепция способности к упорядочению, которая определяется как формальный критерий правильности выполнения некоторого набора параллельных транзак­ций. Потом продолжается рассмотрение некоторых важных уточнений основной идеи блокирования, а именно уровней изоляции и преднамеренной блокиров­ки. Далее описывается, как используются перечисленные выше понятия в стан­дарте языка SQL. И наконец, приводится резюме и несколько заключительных замечаний.

Здесь также уместно привести общие замечания.

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

2. Во-вторых, параллелизм, как и восстановление данных, является весьма обширной темой, а потому в этой главе будут описаны только некоторые наиболее важные идеи. Кроме того, в упражнениях и ответах на них, а также в списке литературы в конце главы содержится обсуждение некоторых последних достижений в этой об­ласти знаний.

14.2. Три проблемы параллелизма

Прежде всего следует уточнить, что каждый метод управления параллелизмом пред­назначен для решения некоторой конкретной задачи. Тем не менее, при обработке правильно составленных транзакций возникают ситуации, которые могут привести к получению неправильного результата из-за взаимных помех среди некоторых тран­закций. (Обратите внимание, что вносящая помеху транзакция сама по себе может быть правильной. Неправильный конечный результат возникает по причине бескон­трольного чередования операций из двух правильных транзакций. Более подробно смысл понятия "правильная транзакция" обсуждается далее в этой книге.) Основные проблемы, возникающие при параллельной обработке транзакций (далее они рас­сматриваются более подробно) следующие:

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

• проблема незафиксированной зависимости;

• проблема несовместимого анализа.

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

Рассмотрим ситуацию, показанную на рис. 14.1, в такой интерпретации: транзакция A извлекает некоторый кортеж p в момент времени t1; транзакция В извлекает некото­рый кортеж р в момент времени t2; транзакция А обновляет некоторый кортеж р (на основе значений, полученных в момент времени t1) в момент времени t3; транзакция В обновляет тот же кортеж р (на основе значений, полученных в момент времени t2, которые имеют те же значения, что и в момент времени //) в момент времени t4. Од­нако результат операции обновления, выполненной транзакцией А, будет утерян, по­скольку в момент времени t4 она не будет учтена и потому будет "отменена" опера­цией обновления, выполненной транзакцией В.

Транзакция А	Время	Транзакция В
-		-
Извлечение кортежа p	T1	-
-		-
-	T2	Извлечение кортежа p
-		-
Обновление кортежа p	T3	-
-		-
-	T4	Обновление кортежа p

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

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

Проблема незафиксированной зависимости появляется, если с помощью некоторой транзакции осуществляется извлечение (или, что еще хуже, обновление) некоторого кортежа, который в данный момент обновляется другой транзакцией, но это обновление еще не закончено. Таким образом, если обновление не завершено, существует некото­рая вероятность того, что оно не будет завершено никогда. (Более того, в подобном случае может быть выполнен возврат к предыдущему состоянию кортежа с отменой выполнения транзакции.) В таком случае в первой транзакции будут принимать участие данные, которых больше не существует (в том смысле, что они "никогда" не существо­вали). Эта ситуация показана на рис. 14.2 и 14.3.

В первом примере (см. рис. 14.2) транзакция А в момент времени t2 встречается с невыполненным обновлением (оно также называется невыполненным изменением). За­тем это обновление отменяется в момент времени t3. Таким образом, транзакция А выполняется на основе фальшивого предположения, что кортеж р имеет некоторое значе­ние в момент времени t2, тогда как на самом деле он имеет некоторое значение, суще­ствовавшее еще в момент времени t1. В итоге после выполнения транзакции А будет получен неверный результат. Кроме того, обратите внимание, что отмена выполнения транзакции В может произойти не по вине транзакции В, а, например, в результате кра­ха системы. (К этому времени выполнение транзакции А может быть уже завершено, а потому крушение системы не приведет к отмене выполнения транзакции A.)

Транзакция А	Время	Транзакция В
-		-
-	T1	Обновление кортежа p
-		-
Извлечение кортежа p	T2	-
-		-
-	T3	Отмена вып. транзакции
-		-

Рис. 14.2. Транзакция А становится зависимой от невыполненного изменения в момент времени t2

Транзакция А	Время	Транзакция В
-		-
-	T1	Обновление кортежа p
-		-
Обновление кортежа p	T2	-
-		-
-	T3	Отмена вып. Транзакции
-		-

Рис. 14.3. Транзакция А обновляет невыполненное изменение в момент времени t2, и результаты этого обновления утрачиваются в момент времени t3

Второй пример, приведенный на рис. 14.3, иллюстрирует более "ужасный" случай. Не только транзакция А становится зависимой от изменения, не выполненного в мо­мент времени t2, но также в момент времени t3 фактически утрачивается результат обновления, поскольку отмена выполнения транзакции В в момент времени t3 приво­дит к восстановлению кортежа р к исходному значению в момент времени t1. Это еще один вариант проблемы потери результатов обновления.

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

На рис. 14.4 показаны транзакции А и В, которые выполняются для кортежей со сче­тами (СЧЕТ). При этом транзакция А суммирует балансы, транзакция В производит перевод суммы 10 со счета 3 на счет 1. Полученный в итоге транзакции А результат 110, очевидно, неверен, и если он будет записан в базе данных, то в ней может воз­никнуть проблема несовместимости. В таком случае говорят, что транзакция А встре­тилась с несовместимым состоянием и на его основе был выполнен несовместимый анализ. Обратите внимание на следующее различие между этим примером и преды­дущим: здесь не идет речь о зависимости транзакции А от транзакции В, так как тран­закция В выполнила все обновления до того, как транзакция А извлекла СЧЕТ 3.